Re: Collect frequency statistics for arrays

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Nathan Boley <npboley@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-01T14:57:17Z
Lists: pgsql-hackers

Attachments

On Thu, Mar 1, 2012 at 1:19 AM, Alexander Korotkov <aekorotkov@gmail.com>wrote:

> On Thu, Mar 1, 2012 at 1:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> That seems like a pretty narrow, uncommon use-case.  Also, to get
>> accurate stats for such queries that way, you'd need really enormous
>> histograms.  I doubt that the existing parameters for histogram size
>> will permit meaningful estimation of more than the first array entry
>> (since we don't make the histogram any larger than we do for a scalar
>> column).
>>
>> The real point here is that the fact that we're storing btree-style
>> stats for arrays is an accident, backed into by having added btree
>> comparators for arrays plus analyze.c's habit of applying default
>> scalar-oriented analysis functions to any type without an explicit
>> typanalyze entry.  I don't recall that we ever thought hard about
>> it or showed that those stats were worth anything.
>>
>
> OK. I don't object to removing btree stats from arrays.
> What do you thinks about pg_stats view in this case? Should it combine
> values histogram and array length histogram in single column like do for
> MCV and MCELEM?
>

Btree statistics for arrays and additional statistics slot are removed from
attached version of patch. pg_stats view is untouched for while.

------
With best regards,
Alexander Korotkov.