On Tue, Mar 3, 2009 at 3:33 AM, Tom Lane wrote:
>
> Because it would be the wrong answer, except in the uncommon case where
> the field values are completely independent (at least, I would expect
> that to be uncommon when people have multicolumn indexes on them).
Actually I think it's *more* li
Merlin Moncure writes:
> On Mon, Mar 2, 2009 at 8:29 PM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> It looks like for row-wise comparison, only the first column is used
>>> for generating the expected row count.
>>
>> [ shrug... ] Short of multi-column statistics, it's hard to see how to
>>
On Mon, Mar 2, 2009 at 8:29 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> It looks like for row-wise comparison, only the first column is used
>> for generating the expected row count.
>
> [ shrug... ] Short of multi-column statistics, it's hard to see how to
> do better.
hm... Why can't you
Merlin Moncure writes:
> It looks like for row-wise comparison, only the first column is used
> for generating the expected row count.
[ shrug... ] Short of multi-column statistics, it's hard to see how to
do better.
regards, tom lane
--
Sent via pgsql-hackers mailing
On Mon, Mar 2, 2009 at 4:43 PM, Merlin Moncure wrote:
> It looks like for row-wise comparison, only the first column is used
> for generating the expected row count. This can lead to bad plans in
> some cases.
>
> Test case (takes seconds to minutes hardware depending):
>
> create table range as
It looks like for row-wise comparison, only the first column is used
for generating the expected row count. This can lead to bad plans in
some cases.
Test case (takes seconds to minutes hardware depending):
create table range as select v as id, v % 500 as key, now() +
((random() * 1000) || 'days
