From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Nathan Boley <npboley(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Collect frequency statistics for arrays |
Date: | 2012-02-29 20:54:35 |
Message-ID: | CAPpHfdvwi-N5Seom_j_MFnO61W5fHJ1g0K1cMwe-GghiXEw3rg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 1, 2012 at 12:39 AM, 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. 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-02-29 20:59:35 | Re: controlling the location of server-side SSL files |
Previous Message | Thom Brown | 2012-02-29 20:50:14 | Re: LIST OWNED BY... |