From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Query plan degradation 8.2 --> 8.3 |
Date: | 2007-05-31 01:03:24 |
Message-ID: | 200705301803.24623.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg,
> How recently did you check out your 8.3 tree?
It's the snapshot from 5/28, which means it was pulled from CVS on 5/27.
So, recent.
> When I run it I get a bitmap index scan which I think might mean you're
> suffering from the same problem Tom found and fixed a few days ago. The
> planner is finding the bitmap index scan with the sort is the best
> possible plan but then discarding that option later leaving it with a
> suboptimal choice.
Apparently. I'll do another build and check.
> It does the right thing if t_s_symb is declared as text instead of
> varchar. When it's varchar, even setting enable_sort off won't make
> it pick the right plan, which suggests that it fails to recognize that
> the index can match the query's ORDER BY. I'm guessing I overlooked
> a binary-compatibility case when I rejiggered the handling of PathKeys
> in connection with the NULLS FIRST/LAST stuff. No time to look deeper
> right now.
Yeah, that looks like the case. We'll move it to TEXT for the tests right
now, but I'll make sure we don't forget this bug during beta. Thanks!
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-05-31 02:08:56 | Re: TOAST usage setting |
Previous Message | Rodrigo Sakai | 2007-05-31 00:41:49 | ERROR: index row size 2960 exceeds btree maximum |