Re: [HACKERS] Query plan degradation 8.2 --> 8.3

2007-05-31 Thread Josh Berkus
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.

Re: [HACKERS] Query plan degradation 8.2 --> 8.3

2007-05-31 Thread Tom Lane
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

Re: [HACKERS] Query plan degradation 8.2 --> 8.3

2007-05-30 Thread Josh Berkus
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 > plann

Re: [HACKERS] Query plan degradation 8.2 --> 8.3

2007-05-30 Thread Gregory Stark
"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 tes

Re: [HACKERS] Query plan degradation 8.2 --> 8.3

2007-05-30 Thread Tom Lane
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

Re: [HACKERS] Query plan degradation 8.2 --> 8.3

2007-05-30 Thread Josh Berkus
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 > the lists but the package is 3.5m, s

[HACKERS] Query plan degradation 8.2 --> 8.3

2007-05-30 Thread Josh Berkus
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 ru