Open poojanilangekar opened 6 years ago
@poojanilangekar Nice!
@mengranwo @GustavoAngulo We need to merge this in ASAP as its blocking the performance benchmarks. Please take a look at it when you get the time.
I think it might be good to keep AnalyzeStatsForAllTables
for now, my group in the class this semester noticed that we don't support the default ANALYZE
behavior like Postgres does, where not specifying a table analyzes all tables. We might want to support this in the future, so that function/logic might come in handy.
As for the the schema, I'm not sure which inconsistency you're referring to @poojanilangekar ? @chenboy do you see an inconsistency?
@GustavoAngulo I have modified the function to AnalyzeStatsForAllTablesWithDatabaseOid
. I checked the Postgres documentation, the ANALYZE
command is run on a per database basis. So I think this should solve the problem.
Regarding the inconsistency, the declaration creates two SKEY indexes and the table has no primary key. While the header file states that the table should contain only one index with the primary key.
The ColumnStatsCatalog
use both indexes.
So I think we should stick to the declaration, not the header.
@GustavoAngulo @camellyx Can you please review these changes?
@pervazea Can you take a look since these other people are out of town?
This is an important PR that we should merge. We don't want to lose track of this.
This PR modifies the
ColumnStatsCatalog
constructor to use a predefined schema instead of using DDL. Additionally, it creates thepg_column_stats
table to a per database basis. Initially this was not done because of the dependencies of theStatsStorage
on the view of "Global Stats".Additionally, it changes the
AnalyzeStatsForAllTables
toAnalyzeStatsForAllTablesWithDatabaseOid
. Now that we maintainColumnStats
on a per database basis, it makes sense to also collect the stats on a per database basis.