Re: Collect frequency statistics for arrays
От | Alexander Korotkov |
---|---|
Тема | Re: Collect frequency statistics for arrays |
Дата | |
Msg-id | CAPpHfdvwi-N5Seom_j_MFnO61W5fHJ1g0K1cMwe-GghiXEw3rg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Collect frequency statistics for arrays (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Collect frequency statistics for arrays
|
Список | pgsql-hackers |
On Thu, Mar 1, 2012 at 12:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
------
With best regards,
Alexander Korotkov.
I am starting to look at this patch now. I'm wondering exactly why thedecision 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:
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.
В списке pgsql-hackers по дате отправления: