Josh Berkus [EMAIL PROTECTED] writes:
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
Tom,
I've applied a patch that fixes this case, but I'm not yet 100%
convinced that there are no other cases where it'll prevent matching
things that should match. Please test.
Will do. We're having trouble building from CVS on the TPCE test rig, so
it'll wait for tommorrow's snapshot.
--
All,
I now have a simple test case which shows significant performance
degradation on 8.3devel for a specific query, apparenly due to an
unnecessary call to Top-N sort. I've tried to forward the test case to
the lists but the package is 3.5m, so I'm putting it on pgFoundry instead:
If you
Josh Berkus [EMAIL PROTECTED] writes:
I now have a simple test case which shows significant performance
degradation on 8.3devel for a specific query, apparenly due to an
unnecessary call to Top-N sort.
It does the right thing if t_s_symb is declared as text instead of
varchar. When it's
Josh Berkus [EMAIL PROTECTED] writes:
On Wednesday 30 May 2007 15:51, Josh Berkus wrote:
I now have a simple test case which shows significant performance
degradation on 8.3devel for a specific query, apparenly due to an
unnecessary call to Top-N sort. I've tried to forward the test case to
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
