Re: Collect frequency statistics for arrays

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Collect frequency statistics for arrays
Дата
Msg-id 25046.1331167902@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Collect frequency statistics for arrays  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: Collect frequency statistics for arrays
Re: Collect frequency statistics for arrays
Список pgsql-hackers
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Mon, Mar 5, 2012 at 1:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Couldn't we reduce the histogram size when there aren't many
>> different counts?
>> 
>> It seems fairly obvious to me that we could bound the histogram
>> size with (max count - min count + 1), but maybe something even
>> tighter would work; or maybe I'm missing something and this would
>> sacrifice accuracy.

> True. If (max count - min count + 1) is small, enumerating of frequencies
> is both more compact and more precise representation. Simultaneously,
> if (max count - min count + 1) is large, we can run out of
> statistics_target with such representation. We can use same representation
> of count distribution as for scalar column value: MCV and HISTOGRAM, but it
> would require additional statkind and statistics slot. Probably, you've
> better ideas?

I wasn't thinking of introducing two different representations,
but just trimming the histogram length when it's larger than necessary.

On reflection my idea above is wrong; for example assume that we have a
column with 900 arrays of length 1 and 100 arrays of length 2.  Going by
what I said, we'd reduce the histogram to {1,2}, which might accurately
capture the set of lengths present but fails to show that 1 is much more
common than 2.  However, a histogram {1,1,1,1,1,1,1,1,1,2} (ten entries)
would capture the situation perfectly in one-tenth the space that the
current logic does.

More generally, by limiting the histogram to statistics_target entries,
we are already accepting errors of up to 1/(2*statistics_target) in the
accuracy of the bin-boundary representation.  What the above example
shows is that sometimes we could meet the same accuracy requirement with
fewer entries.  I'm not sure how this could be mechanized but it seems
worth thinking about.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql_fdw, FDW for PostgreSQL server
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Custom Operators Cannot be Found for Composite Type Values