Re: Collect frequency statistics for arrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Boley <npboley(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collect frequency statistics for arrays
Date: 2012-02-29 22:43:56
Message-ID: 22715.1330555436@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Boley <npboley(at)gmail(dot)com> writes:
> On Wed, Feb 29, 2012 at 12:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-02-29 22:52:34 Re: 16-bit page checksums for 9.2
Previous Message Robert Haas 2012-02-29 22:40:23 Re: Parameterized-path cost comparisons need some work