You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
947: Fix parameter context for statement_timeout and recovery_target_name
The statement_timeout parameter had the wrong context configured, which prevented users from being able to change its value. I did a quick skim of Doltgres' parameters and compared them to pg_catalog.pg_settings and found one other parameter context (recovery_target_name) that didn't match.
Fixes: #943
942: Removed doltgres user and default database
This removes the default doltgres user, so that we're more in-line with a standard Postgres installation. In addition, this also removes the default doltgres database, and fully replaces it with a postgres database. Postgres creates this database by default, so it's best that we mimic it.
In addition, Postgres uses the username as the database name if a database name is not given, and I'm sure many users simply use the postgres user without even thinking about what database they're connecting to, so this allows for that workflow to work as expected.
941: throw unsupported error for PARTITION OF statements
Catch PARTITION OF statements and return error instead of panicking.
940: Add caching for pg_catalog tables
While investigating performance on some skipped tests for pg_catalog tables, I found a few areas to optimize around how we deal with OIDs. The biggest source of latency I found was that pg_catalog tables must iterate through every object in a database (e.g. schemas, tables, indexes, types) to generate OIDs and create the rows for each pg_catalog table. When multiple pg_catalog tables are joined together, this starts to consume a significant amount of time, with some queries triggering this database iteration process hundreds of thousands of times.
This change creates a new cache in the session object that stores the data for pg_catalog tables so that it can be reused within the same query. The effect is that several queries that timed out before will now complete. Some of these queries are still slow (e.g. multiple seconds to execute) and can be further optimized. The biggest source of latency now seems to be from the join operations, since the data is currently not eligible for point lookups and has to be scanned repeatedly to stitch rows together.
Another area for future optimization is the regclass/regtype/regprocIO_Output and IO_Input functions, which also trigger iterations over database objects to turn a relation name into an OID, and to turn an OID into a relation name.
Longer term, instead of relying on iterating database objects and caching OID information, we eventually need to store this information so it can be quickly loaded, and keep it in sync as database objects are created/modified/deleted, including changes made through merges, resets, and other database version control changes.
939: Unskip many InsertInto engine tests
This adds several new features / bug fixes found during testing:
DROP INDEX support
Support for ON CONFLICT UPDATE
Panic during insert of some UNION statements
Fixed case sensitivity bug in column names for INSERT statements
936: Release v0.14.0
Created by the Release workflow to update DoltgreSQL's version
935: implement multiple table inherits
This PR supports most of the functionality around PostgreSQL INHERITs.
We just translate create table t1 (...) inherits (t2, t3, ...); to create table t1 like (t2, t3, ...);
Note: MySQL does not support multiple LIKE statements
gms logic: dolthub/go-mysql-server#2738
syntax: dolthub/vitess#375