Re: Collect frequency statistics for arrays - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Collect frequency statistics for arrays
Date
Msg-id CA+Tgmob1zxaLKOuuD9wUygVAneG_ePPjA8pzhOD8s29O=xfZ6A@mail.gmail.com
Whole thread Raw
In response to Re: Collect frequency statistics for arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Collect frequency statistics for arrays  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Wed, Feb 29, 2012 at 5:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Nathan Boley <npboley@gmail.com> writes:
>> On Wed, Feb 29, 2012 at 12:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I am starting to look at this patch now.  I'm wondering exactly why the
>>> decision was made to continue storing btree-style statistics for arrays,
>>> in addition to the new stuff.
>
>> If I understand you're suggestion, queries of the form
>
>> SELECT * FROM rel
>> WHERE ARRAY[ 1,2,3,4 ] <= x
>>      AND x <=ARRAY[ 1, 2, 3, 1000];
>
>> would no longer use an index. Is that correct?
>
> No, just that we'd no longer have statistics relevant to that, and would
> have to fall back on default selectivity assumptions.  Do you think that
> such applications are so common as to justify bloating pg_statistic for
> everybody that uses arrays?

I confess I am nervous about ripping this out.  I am pretty sure we
will get complaints about it.  Performance optimizations that benefit
group A at the expense of group B are always iffy, and I'm not sure
the case of using an array as a path indicator is as uncommon as you
seem to think.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Collect frequency statistics for arrays
Next
From: Alvaro Herrera
Date:
Subject: Re: Collect frequency statistics for arrays