Re: [HACKERS] multivariate statistics (v19)

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: [HACKERS] multivariate statistics (v19)
Дата
Msg-id c2e06040-3b23-72a3-028c-ec54147b2aab@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] multivariate statistics (v19)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [HACKERS] multivariate statistics (v19)  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] multivariate statistics (v19)  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On 01/30/2017 09:37 PM, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> The 'built' flags may be easily replaced with a check if the bytea-like
>> columns are NULL, and the 'enabled' columns may be replaced by the array of
>> char, just like you proposed.
>>
>> That'd give us a single catalog looking like this:
>>
>> pg_mv_statistics
>>   starelid
>>   staname
>>   stanamespace
>>   staowner      -- all the above as currently
>>   staenabled    array of "char" {d,f,s}
>>   stakeys
>>   stadeps  (dependencies)
>>   standist (ndistinct coefficients)
>>   stamcv   (MCV list)
>>   stahist  (histogram)
>>
>> Which is probably a better / simpler structure than the current one.
>
> Looks good to me.  I don't think we need to keep the names very short --
> I would propose "standistinct", "stahistogram", "stadependencies".
>

Yeah, I got annoyed by the short names too.

This however reminds me that perhaps pg_mv_statistic is not the best 
name. I know others proposed pg_statistic_ext (and pg_stats_ext), and 
while I wasn't a big fan initially, I think it's a better name. People 
generally don't know what 'multivariate' means, while 'extended' is 
better known (e.g. because Oracle uses it for similar stuff).

So I think I'll switch to that name too.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commitid: 69f4b9c85f)