Tom Lane wrote: > I don't think any of this is out of reach, but it'd be a nontrivial > bit of implementation effort (maybe a week or three) and it also looks > like there might be a measurable planning slowdown for any query > involving subqueries. I'm not sure yet how much of this is just moving > existing work around and how much will actually represent new planning > expense. But certainly, costing EXISTS subqueries two different ways > isn't going to be free.
The typical comment around here is that it's usually a huge win when a bit of CPU time is spent in buying I/O savings. Since most servers are I/O bound anyway, and since most servers nowadays are typically oversized in CPU terms, this strikes me as the good tradeoff to be making. In any case, most of the time EXISTS queries are expensive queries, so spending more time planning them is probably good. It'd be a shame to spend a lot of time planning queries that are trivial in execution costs, but I wouldn't expect this to be the case here. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
