Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[BACKPORT 2.20][#23786] YSQL: yb_make_next_ddl_statement_nonincrementing
Summary:
In a recent customer issue investigation, the customer performed an application
upgrade, which involves running many DDLs (100+) consecutively. Many of these
DDLs cause catalog version to increment. As a result, all the active connections
kept doing catalog cache refreshes continuously that led to PG memory spike and
latency spike. It will be beneficial to reduce the number of DDLs that
increment the catalog version. After analyzing customer's DDL statements that
have caused catalog version to increment, they can be classified as 3 categories:
(1) create index statements that build indexes on a newly created table
(2) create new partition statements and link them to the existing parent partition
(3) create new table but referencing an existing table via foreign key
For (1), because the table itself is newly created, there is no need for the
create index statement to increment the catalog version. To make things worse, a
create index statement by default runs concurrently, and increments the catalog
version by 3.
In this particular customer's situation, more than half of the DDLs belong to
category (1).
One solution is to combine create statement and the create index statement
together. Using an example found online:
```
yugabyte=# create table foo (
yugabyte(# id serial primary key,
yugabyte(# code integer,
yugabyte(# label text);
CREATE TABLE
yugabyte=# create unique index foo_idx on foo using btree (code, label);
NOTICE: index method "btree" was replaced with "lsm" in YugabyteDB
CREATE INDEX
yugabyte=# select * from pg_yb_catalog_version;
db_oid | current_version | last_breaking_version
--------+-----------------+-----------------------
1 | 1 | 1
13248 | 1 | 1
13249 | 1 | 1
13251 | 4 | 1
13252 | 1 | 1
(5 rows)
```
By create table and then create a unique index, the catalog version was
incremented by 3.
On the other hand, we can combine them into one create table statement:
```
yugabyte=# create table foo (
yugabyte(# id serial primary key,
yugabyte(# code integer,
yugabyte(# label text,
yugabyte(# constraint foo_uq unique (code, label));
select *CREATE TABLE
yugabyte=# select * from pg_yb_catalog_version;
db_oid | current_version | last_breaking_version
--------+-----------------+-----------------------
1 | 1 | 1
13248 | 1 | 1
13249 | 1 | 1
13251 | 1 | 1
13252 | 1 | 1
(5 rows)
```
We can see that there was no catalog version increment.
However it is not always possible to do these rewrite. The create index
statement does allow more options, such as specifying ASC, DESC which isn't
allowed when declaring a uniqe constraint in the create table statement itself.
It is in such a case we introduce the new GUC
`yb_make_next_ddl_statement_nonincrementing` to help. This is an auto-reset gflag
that is done similar to the existing GUC
`yb_make_next_ddl_statement_nonbreaking`. When set to true, it will suppress the
next DDL statement from incrementing both the `current_version` and the
`last_breaking_version`.
Note that in order for the GUC to work for create index statement, we need to
use the nonconcurrent keyword. By default the create index statement runs
concurrently and its algorithm involves incrementing the catalog version by 3 to
work correctly. A create index noncurrently only bumps up the catalog version by
1. For a newly created table, because it is empty, it is safe and correct to run
create index nonconcurrently.
For example,
```
yugabyte=# create table foo(id int);
CREATE TABLE
yugabyte=# select * from pg_yb_catalog_version;
db_oid | current_version | last_breaking_version
--------+-----------------+-----------------------
1 | 1 | 1
13248 | 1 | 1
13249 | 1 | 1
13251 | 1 | 1
13252 | 1 | 1
(5 rows)
yugabyte=# create index nonconcurrently id_idx on foo(id);
CREATE INDEX
yugabyte=# select * from pg_yb_catalog_version;
db_oid | current_version | last_breaking_version
--------+-----------------+-----------------------
1 | 1 | 1
13248 | 1 | 1
13249 | 1 | 1
13251 | 2 | 1
13252 | 1 | 1
(5 rows)
```
With the new GUC `yb_make_next_ddl_statement_nonincrementing`, the catalog
version will stay the same:
```
yugabyte=# create table foo(id int);
CREATE TABLE
yugabyte=# select * from pg_yb_catalog_version;
db_oid | current_version | last_breaking_version
--------+-----------------+-----------------------
1 | 1 | 1
13248 | 1 | 1
13249 | 1 | 1
13251 | 1 | 1
13252 | 1 | 1
(5 rows)
yugabyte=# set yb_make_next_ddl_statement_nonincrementing = true;
SET
yugabyte=# create index nonconcurrently id_idx on foo(id);
CREATE INDEX
yugabyte=# select * from pg_yb_catalog_version;
db_oid | current_version | last_breaking_version
--------+-----------------+-----------------------
1 | 1 | 1
13248 | 1 | 1
13249 | 1 | 1
13251 | 1 | 1
13252 | 1 | 1
(5 rows)
```
A new unit test is added.
Jira: DB-12689
Original commit: 063dbe5 / D37915
Test Plan: ./yb_build.sh --cxx-test pg_catalog_version-test --gtest_filter PgCatalogVersionTest.NonIncrementingDDLMode
Reviewers: kfranz
Reviewed By: kfranz
Subscribers: yql, svc_phabricator
Differential Revision: https://phorge.dev.yugabyte.com/D38128- Loading branch information
