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-02-29T20:54:35Z
Lists: pgsql-hackers
On Thu, Mar 1, 2012 at 12:39 AM, 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.  The pg_statistic rows for array columns
> tend to be unreasonably wide already, and as-is this patch will make
> them quite a lot wider.  I think it requires more than a little bit of
> evidence to continue storing stats that seem to have only small
> probability of usefulness.
>
> In particular, if we didn't store that stuff, we'd not need to widen the
> number of columns in pg_statistic, which would noticeably reduce both
> the footprint of the patch and the probability of breaking external
> code.
>

Initially, I used existing slots for new statistics, but I've changed this
after the first review:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00780.php

Probably, btree statistics really does matter for some sort of arrays? For
example, arrays representing paths in the tree. We could request a subtree
in a range query on such arrays.

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