Re: [HACKERS] multivariate statistics (v24) - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: [HACKERS] multivariate statistics (v24)
Date
Msg-id a78ffb17-70e8-a55a-c10c-66ab575e88ed@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] multivariate statistics (v19)  (David Fetter <david@fetter.org>)
Responses Re: [HACKERS] multivariate statistics (v24)  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: [HACKERS] multivariate statistics (v24)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
OK,

attached is v24 of the patch series, addressing most of the reported 
issues and comments (at least I believe so). The main changes are:

1) I've mostly abandoned the "multivariate" name in favor of "extended", 
particularly in places referring to stats stored in the pg_statistic_ext 
in general. "Multivariate" is now used only in places talking about 
particular types (e.g. multivariate histograms).

The "extended" name is more widely used for this type of statistics, and 
the assumption is that we'll also add other (non-multivariate) types of 
statistics - e.g. statistics on custom expressions, or some for of join 
statistics.

2) Catalog pg_mv_statistic was renamed to pg_statistic_ext (and 
pg_mv_stats view renamed to pg_stats_ext).

3) The structure of pg_statistic_ext was changed as proposed by Alvaro, 
i.e. the boolean flags were removed and instead we have just a single 
"char[]" column with list of enabled statistics.

4) I also got rid of the "mv" part in most variable/function/constant 
names, replacing it by "ext" or something similar. Also mvstats.h got 
renamed to stats.h.

5) Moved the files from src/backend/utils/mvstats to backend/statistics.

6) Fixed the n_choose_k() overflow issues by using the algorithm 
proposed by Dean. Also, use the simple formula for num_combinations().

7) I've tweaked data types for a few struct members (in stats.h). I've 
kept most of the uint32 fields at the top level though, because int16 
might not be large enough for large statistics and the overhead is 
minimal (compared to the space needed e.g. for histogram buckets).


The renames/changes were quite widespread, but I've done my best to fix 
all the comments and various other places.

regards

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: vinayak
Date:
Subject: Re: [HACKERS] Transactions involving multiple postgres foreignservers
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock