Dave Cramer writes:
> This query is a couple orders of magnitude slower the first result is
> 9.2.1, the second 9.1
Thanks for sending me the test case off-list. I found the reason why
I'd not been able to reproduce the problem: the index you're hoping it
will use is declared
"note_sets_parent_
Willem Leenen writes:
> To me, i see a mismatch between the optimizer and the actual records
> retrieved in the fast SQL as well, so plan instability is a realistic
> scenario.
Well, the rowcount estimates for a recursive union are certainly
pretty bogus, but those are the same either way. The r
et))
IMHO, the plan goes wrong at the part
SELECT note_sets.id FROM
parent_noteset parent_noteset,
note_sets note_sets
WHERE note_sets.parent_id = parent_noteset.id)
Do you agree?
> From: t...@sss.pgh.pa.us
> To: p...@fastcrypt.com
> CC: pgsql-performance@postgresql.org
&g
Tom,
Will try to get one ASAP.
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Mon, Nov 12, 2012 at 3:43 PM, Tom Lane wrote:
> Dave Cramer writes:
> > This query is a couple orders of magnitude slower the first result is
> > 9.2.1, the second 9.1
>
> Hm, the plan
Dave Cramer writes:
> This query is a couple orders of magnitude slower the first result is
> 9.2.1, the second 9.1
Hm, the planner's evidently doing the wrong thing inside the recursive
union, but not obvious why. Can you extract a self-contained test case?
regards, tom
This query is a couple orders of magnitude slower the first result is
9.2.1, the second 9.1
=# explain analyze SELECT note_sets."id" AS t0_r0,
note_sets."note_set_source_id" AS t0_r1, note_sets."parent_id" AS t0_r2,
note_sets."business_entity_id" AS t0_r3, note_sets."created_at" AS t0_r4,
note_set
