>>> On Mon, Oct 22, 2007 at 1:30 PM, in message
<[EMAIL PROTECTED]>, Simon Riggs <[EMAIL PROTECTED]>
wrote:
> On Mon, 2007-10-22 at 09:31 -0500, Kevin Grittner wrote:
>> I've requested this before without response, but I'm asking again
>> because it just caused me pain again: could we get a TODO added to
>> have the planner recognize equivalent IN and EXISTS constructs and
>> have them compete on cost estimates? I know it's not a trivial
>> improvement, but if it's on the list maybe someone will pick it up,
>> and I see it as the single biggest weakness in PostgreSQL
>> performance.
>
> I'll pick it up as a default unless someone requests they have it from
> me.
Thanks, Simon.
One more logically equivalent, PostgreSQL-specific form which
costs out even better was suggested off-list:
step=# explain DELETE FROM "Body" USING "Message" WHERE "Message"."bodySeqNo" =
"Body"."bodySeqNo";
QUERY PLAN
--------------------------------------------------------------------------------------------------
Merge Join (cost=0.00..696766.20 rows=4048543 width=6)
Merge Cond: (("Body"."bodySeqNo")::numeric =
("Message"."bodySeqNo")::numeric)
-> Index Scan using "Body_pkey" on "Body" (cost=0.00..326108.11
rows=4048543 width=18)
-> Index Scan using "Message_Body" on "Message" (cost=0.00..310085.16
rows=4048847 width=12)
(4 rows)
If both of the other syntaxes could compete against that, it would
be fantastic. (If that's feasible.)
-Kevin
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
