Yes I remember our talk. Thanks for the the link and the performance test. One problem that I have with such testing is that the speedup number is somewhat arbitrary: one could make the eliminated table bigger by putting bigger TEXT data into it, and/or one could use an example where join removal would remove multiple tables.

I would argue that your example shows least possible speedup as the example removes only one table with relatively small columns

Maybe you remeber me, we talked about this feature after your presentation at FOSDEM.

Inspired by your presentation i have made a test with PostgreSQL. Our upcoming release 9.0 contains a similar feature, we called it join removal (as Stefan Kaltenbrunner said).

http://akretschmer.blogspot.com/2010/02/join-removal-short-performance-test.html

Thanks for the pointer. It would be interesting to compare the features.

The SQL layer will not touch any records in eliminated tables, so no locks will
be placed on any records from eliminated tables.

With regards to correctness of this, first I doubt that there is a clear
definition of what should happen with SELECT … FOR UPDATE with outer joins
(PostgreSQL would give error when one attempts to do this IIRC).

If we stretch the FOR UPDATE definition to cover outer joins, then I still
think current behavior is correct: one of the necessary conditions to
eliminate a table is that it must not be referred from the select list. I
interpret it as that we selected nothing from the eliminated table and hence
don’t need to place any locks.

SELECT .. FOR UPDATE won’t place any locks for tables inside subqueries,
including FROM-subqueries, why inner sides of outer joins that don’t get
to select list should be any better?

http://developer.postgresql.org/pgdocs/postgres/release-8-5.html