Re: Statistics Import and Export
От | Corey Huinker |
---|---|
Тема | Re: Statistics Import and Export |
Дата | |
Msg-id | CADkLM=fZWAPyDxmHqxiJMUvrjbi2Fo1pHr+63_1d8yhStZ=sXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Statistics Import and Export (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Statistics Import and Export
|
Список | pgsql-hackers |
To my mind the next task is to get the buildfarm green again by
fixing the expression-index-stats problem. I can have a go at
that once Jeff pushes these patches, unless one of you are already
on it?
Already on it, but I can step aside if you've got a clearer vision of how to solve it.
My solution so far is to take allo the v11+ (SELECT array_agg...) functions and put them into a LATERAL, two of them filtered by attstattarget > 0 and a new one aggregating attnames with no filter.
An alternative would be a new subselect for array_agg(attname) WHERE in.indexprs IS NOT NULL, thus removing the extra compute for the indexes that lack an index expression (i.e. most of them), and thus lack settable stats (at least for now) and wouldn't be affected by the name-jitter issue anyway.
I'm on the fence about how to handle pg_clear_attribute_stats(), leaning toward overloaded functions.
My solution so far is to take allo the v11+ (SELECT array_agg...) functions and put them into a LATERAL, two of them filtered by attstattarget > 0 and a new one aggregating attnames with no filter.
An alternative would be a new subselect for array_agg(attname) WHERE in.indexprs IS NOT NULL, thus removing the extra compute for the indexes that lack an index expression (i.e. most of them), and thus lack settable stats (at least for now) and wouldn't be affected by the name-jitter issue anyway.
I'm on the fence about how to handle pg_clear_attribute_stats(), leaning toward overloaded functions.
В списке pgsql-hackers по дате отправления: