Tom,
Just to confirm you that your last commit fixed the problem:
lbo=# explain analyze select * from cms_items where ancestors LIKE '1062/%';
QUERY PLAN
-
On Nov 9, 2007 5:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> he's got no MCVs, presumably because the field
> is unique.
It is. The ancestors field contains the current folder itself so the
id of the folder (which is the primary key) is in it.
--
Guillaume
---(end of bro
Gregory Stark <[EMAIL PROTECTED]> writes:
> Could we not use the bogus range to calculate the histogram estimate
> but apply the LIKE pattern directly to the most-frequent-values
> instead of applying the bogus range? Or would that be too much code
> re-organization for now?
We have already done t
"Tom Lane" <[EMAIL PROTECTED]> writes:
> This rule works for all the locales I have installed ... but I don't
> have any Far Eastern locales installed. Also, my test cases are only
> covering ASCII characters, and I believe many locales have some non-ASCII
> letters that sort after 'Z'. I'm not
On Nov 9, 2007 3:08 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> This rule works for all the locales I have installed ... but I don't
> have any Far Eastern locales installed. Also, my test cases are only
> covering ASCII characters, and I believe many locales have some non-ASCII
> letters that sort
I wrote:
> I did do some experimentation and found that among the ASCII characters
> (ie, codes 32-126), nearly all the non-C locales on my Fedora machine
> sort Z last and z next-to-last or vice versa. Most of the remainder
> sort digits last and z or Z as the last non-digit character. Since Z i
Gregory Stark <[EMAIL PROTECTED]> writes:
> Doesn't really strike at the core reason that this is so klugy though. Surely
> the "right" thing is to push the concept of open versus closed end-points
> through deeper into the estimation logic?
No, the right thing is to take the folk who defined "dic
"Tom Lane" <[EMAIL PROTECTED]> writes:
> What I am tempted to do about this is have make_greater_string tack "zz"
> onto the supplied prefix, so that it would have to find a string that
> compares greater than "123/zz" before reporting success. This is
> getting pretty klugy though, so cc'ing to
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On Nov 8, 2007 12:14 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I've applied a patch that might help you:
>> http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php
> AFAICS, it doesn't seem to fix the problem. I just compiled
> REL8_1_ST
