Re: multivariate statistics v8
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-01-20T19:20:38Z
Lists: pgsql-hackers
On Wed, Dec 23, 2015 at 2:07 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > The remaining question is how unique the statistics name should be. > My initial plan was to make it unique within a table, but that of > course does not work well with the DROP STATISTICS (it'd have to > specify the table name also), and it'd also now work with statistics > on multiple tables (which is one of the reasons for abandoning ALTER > TABLE stuff). > > So I think it should be unique across tables. Statistics are hardly > a global object, so it should be unique within a schema. I thought > that simply using the schema of the table would work, but that of > course breaks with multiple tables in different schemas. So the only > solution seems to be explicit schema for statistics. That solution seems good to me. (with apologies for not having looked at the rest of this much at all) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Collect and use multi-column dependency stats
- 2686ee1b7ccf 10.0 landed
-
Implement SortSupport for macaddr data type
- f90d23d0c518 10.0 cited
-
Implement multivariate n-distinct coefficients
- 7b504eb282ca 10.0 landed
-
Generate fmgr prototypes automatically
- 352a24a1f9d6 10.0 cited