I previously blogged about ensuring that the “ON CONFLICT” directive is used in order to avoid vacuum from having to do additional work. You can read the original blog here: Reduce Vacuum by Using “ON CONFLICT” Directive
Now that Postgres has incorporated the “MERGE” functionality into Postgres 15 and above, I wanted to ensure that there was no “strange” behavior as it relates to vacuum when using merge. As you can see here, the “MERGE” functionality does perform exactly as expected. For example, when you attempt to have a merge where the directive is to try an insert first followed by an update, exactly one row is marked dead when the insert fails and the update succeeds.
/* Create the table: */
CREATE TABLE public.pk_violation_test (
id int PRIMARY KEY,
value numeric,
product_id int,
effective_date timestamp(3)
);
/* Insert some mocked up data */
INSERT INTO public.pk_violation_test VALUES (
generate_series(0,10000),
random()*1000,
random()*100,
current_timestamp(3));
/* Verify that there are no dead tuples: */
SELECT
schemaname,
relname,
n_live_tup,
n_dead_tup
FROM
pg_stat_all_tables
WHERE
relname = 'pk_violation_test';
schemaname | relname | n_live_tup | n_dead_tup
------------+-------------------+------------+------------
public | pk_violation_test | 100001 | 0
Then, create a simple merge and check the results:
WITH insert_query AS (
SELECT
0 AS id,
44.33893489873 AS value,
46 AS product_id,
now() AS effective_date) MERGE INTO pk_violation_test pkt
USING insert_query i ON pkt.id = i.id
WHEN MATCHED THEN
UPDATE SET
value = i.value, product_id = i.product_id, effective_date = i.effective_date
WHEN NOT MATCHED THEN
INSERT (id, value, product_id, effective_date)
VALUES (i.id, i.value, i.product_id, i.effective_date);
MERGE 1
And then check the dead tuple count:
SELECT
schemaname,
relname,
n_live_tup,
n_dead_tup
FROM
pg_stat_all_tables
WHERE
relname = 'pk_violation_test';
schemaname | relname | n_live_tup | n_dead_tup
------------+-------------------+------------+------------
public | pk_violation_test | 10001 | 1
(1 row)
As expected only one row is marked dead. Merge is such great functionality and I am glad to see it in Postgres. As you get time, all of your “ON CONFLICT” statements should be converted to use this functionality. Enjoy!
There are several benefits to using temp tables in SQL DML operations. Given my long relationship and work on Oracle databases, I am highly familiar with the Oracle style “Global Temporary Tables” and have used them to solve many performance issues when complex joins are involved. That’s why I was excited when Gilles Darold released the extension “pgtt” for PostgreSQL. I was even more excited when Google released the extension for use in the Google CloudSQL for Postgres and AlloyDB for Postgres products.
In my opinion, native Postgres temporary tables leave a lot to be desired. For example, each table has to be created upon use. Nothing is persistent. This takes time and leads to Postgres catalog bloat (looking to do a post on this soon). That being said, in self managed instances, ‘pgtt’ is very easy to use. You can load the extension either at connection time by user, or for anyone that connects to a database. For example (make sure the extension is created in the database before setting these):
alter role test_user SET session_preload_libraries to 'pgtt';
alter database test_pgtt SET session_preload_libraries = 'pgtt';
This will, by default, use the ‘pgtt’ version of temporary tables instead of the default temporary tables Postgres offers. You can then create ‘pgtt’ style tables and refer to them via the pgtt_schema with no further modifications.
To revert back in the session, you must “disconnect” the session alter the user / database to revert the behavior to “old” style temporary tables. To my knowledge, if the library is enabled this way there is no way to use both styles of temporary tables at the same time.
alter role test_user RESET session_preload_libraries;
alter database pgtt_test RESET session_preload_libraries;
The Set Up…..
/* set flag "pgtt.enabled" on alloydb / cloudsql postgres console to on */
/* create the extension in every database you need to use global temp tables */
CREATE EXTENSION pgtt;
LOAD 'pgtt';
/* Additional extensions needed for this test */
CREATE EXTENSION "uuid-ossp";
/* create the persistent global temporary table */
CREATE /*GLOBAL*/ TEMPORARY TABLE test_gtt_table (
id integer,
lbl text) ON COMMIT DELETE ROWS;
/* create an index on the global temp table */
CREATE INDEX ON pgtt_schema.test_gtt_table (id);
Use of ‘pgtt’ in Cloud Database Products
When you look at managed Cloud databases (from any vendor), you have to understand that some items need to be locked down in order to safeguard against the “managed” nature of the product. Unfortunately (as of this writing), at least in Google Cloud Postgres products, you cannot manipulate the parameter “session_preload_libraries”. So then you ask “How can I programmatically use the extension”? As the time of this writing, I have found only two ways. Either the user has to explicitly execute “LOAD ‘pgtt'” at the beginning / at some point in their session or the “LOAD” must be embedded in a function / procedure similar to the following:
/* function definition with loading of extension as a work around */
create or replace function public.test_gtt_function(P_IN_IDS integer[])
returns table (
id integer,
lbl text
)
language plpgsql
AS $func$
BEGIN
LOAD 'pgtt';
/* revised query below */
INSERT INTO pgtt_schema.test_gtt_table
select generate_series,substr(uuid_generate_v4()::text,1,15) FROM generate_series(1, 5000);
RETURN QUERY
SELECT mygtt.id,mygtt.lbl from pgtt_schema.test_gtt_table mygtt where mygtt.id = ANY (P_IN_IDS);
END
$func$;
As you can see in the above function, the “LOAD” directive is the first thing in the function. While I am not a fan of having to do it this way, there doesn’t seem to be a huge performance impact but one nonetheless that you must account for:
(postgres@##########:5432) [tpcc] > LOAD 'pgtt';
LOAD
Time: 3.811 ms
(postgres@##########:5432) [tpcc] > \watch 1
LOAD
Time: 2.922 ms
LOAD
Time: 1.219 ms
LOAD
Time: 1.335 ms
LOAD
Time: 1.300 ms
LOAD
Time: 1.282 ms
LOAD
One reason I do like the implementation within the function is that it is easier to remove the directive vs the directive being embedded within the code. Either way the right direction is to get the vendor to allow targeted values for this parameter. This will allow the most flexibility and the least amount of awareness and hassle when using this extension.
So What Happens If You Don’t Load The Library??
So if you do not load the library with one of the options above, the functions still works. But what happens? The table actually behaves as a “real” table and the data is never truncated… Even after disconnection:
Pretty crazy. So if for some reason the LOAD does not occur or fails, there could be an issue where the temp table has duplicate rows.
So what happens if the “pgtt” temp table was never created? You get a failure as you expect:
(postgres@#######:5432) [tpcc] > select * from public.test_gtt_wo_load_function(:ids);
ERROR: relation "pgtt_schema.test_gtt_table" does not exist
LINE 1: INSERT INTO pgtt_schema.test_gtt_table
^
QUERY: INSERT INTO pgtt_schema.test_gtt_table
select generate_series,substr(uuid_generate_v4()::text,1,15) FROM generate_series(1, 5000)
CONTEXT: PL/pgSQL function test_gtt_wo_load_function(integer[]) line 4 at SQL statement
Time: 5.204 ms
So it is important to ensure that if you intend to use “pgtt” you have a programmatic method to load the extension….. and in the meantime, I will be working on my end to get a cleaner way to load it in the managed products I have access to.
In Oracle, right or wrong, I was always taught to try to avoid “row movement” between partitions due to the general thought that the extra workload of a “delete” + “insert” (rewrite of the row) should be avoided due to the extra I/O, index fragmentation and the associated risks of a migrating ROWID in the cases where the app developers might have used it in their code (now that’s a whole other problem). Oracle didn’t even let you do it by default.
Table by table, you had to explicitly set:
alter table [table name] enable row movement;
Now, you also had to set this to do table reorganizations such as “alter table…. shrink space / shrink space compact” so it wasn’t something unheard of. However, when a customer recently explained to me that they were going to partition a PostgreSQL table and update the partition key column from null to the date when the row got processed, my mind immediately went to the space of that’s probably bad……. RIGHT??
Well, once I thought about it, maybe it’s not all that bad due to the way MVCC and the subsequent VACUUM operations occur in PostgreSQL. The only thing I could think of that might be a factor is that you would lose any potential benefit of HOT (Heap-Only-Tuple) updates since the row will no longer be part of the original partition, seeing that partitions in PostgreSQL are just another table. The benefit though is that I could limit my vacuum operations to one single partition and SMALLER table. A plus for this customer.
**** Note: An implementation like this does not necessarily follow best practices with regards to partitioning. That being said, I was attempting to validate the idea with regards to how PostgreSQL MVCC behaves.
That being said, I wanted to at least be able to prove / disprove my thoughts with a demonstration, so off to PostgreSQL we go. First let’s create a simple partitioned table and use pg_partman to help:
CREATE TABLE partman_test.partman_partitioned (
id integer not null,
val varchar(20) not null,
created_tmstp timestamp not null,
event_tmstp timestamp null)
PARTITION BY RANGE (event_tmstp);
CREATE INDEX partman_partitioned_ix1 ON partman_test.partman_partitioned (id);
SELECT partman.create_parent( p_parent_table => 'partman_test.partman_partitioned',
p_control => 'event_tmstp',
p_type => 'native',
p_interval=> 'daily',
p_premake => 3);
Now, lets insert some random data using a date randomizer function to spread the data across new partitions:
CREATE OR REPLACE FUNCTION partman_test.random_date(out random_date_entry timestamp) AS $$
select current_timestamp(3) + random() * interval '2 days'
$$ LANGUAGE SQL;
INSERT INTO partman_test.partman_partitioned VALUES (
generate_series(0,10000),
substr(md5(random()::text), 0,10),
partman_test.random_date(),
NULL);
And then for demonstration purposes, I will set autovacuum to “off” for all the partitions” and run 100 updates to move the data into random partitions using the following statement:
ALTER TABLE partman_test.partman_partitioned_default SET (autovacuum_enabled = false);
ALTER TABLE partman_test.partman_partitioned_p2023_09_05 SET (autovacuum_enabled = false);
ALTER TABLE partman_test.partman_partitioned_p2023_09_06 SET (autovacuum_enabled = false);
ALTER TABLE partman_test.partman_partitioned_p2023_09_07 SET (autovacuum_enabled = false);
do $$
declare
v_id integer;
begin
for cnt in 1..100 loop
select id
FROM partman_test.partman_partitioned
WHERE event_tmstp is null
LIMIT 1 FOR UPDATE SKIP LOCKED
INTO v_id;
UPDATE partman_test.partman_partitioned
SET event_tmstp = partman_test.random_date()
WHERE id = v_id and event_tmstp is null;
commit;
end loop;
end; $$;
Once the updates finish, let’s look at the vacuum stats:
Extension “pg_stattuple” confirms that dead tuples only exist in the “default” partition. The reason as to why the numbers don’t match pg_stat_all_tables is a discussion for another day:
So, we definitely proved that we didn’t get the benefit of HOT updates, but due to the MVCC model of PostgreSQL, the update becomes just like any other non-HOT update. This is due to the fact that the updated row is behaving as if it had an index on the row (primary cause of a non-HOT update and sometimes common) and the rest of the MVCC model is just behaving as it would anyway. I did want to validate with one more tool, but unfortunately the extension, “pg_walinspect” was not installed on this CloudSQL for Postgres instance so I was unable to use it.
What about locks? We do get additional locks to manage because we are effecting two partitions instead of one (but they are all fastpath locks):
Also, be aware that you may need to pay special attention to the vacuum operations and settings of the default partition as this type of operation may cause some significant bloat over time. However, one positive is that the bloat will be contained to one and only one partition.
One last caveat that comes to mind. Be sure that either you specify the partition key or explicitly update the “default” partition in your query because otherwise you would get a multiple partition scan which could cause other performance and locking issues.
For those who have worked with Oracle, the pg_hint_plan extension is one that will allow you to hint plans in patterns that you are likely very familiar with:
sql_patch
sql_profile
sql_plan_baselines
While currently, the functionality provided by pg_hint_plan is not nearly as robust (hints list), it does provide most of what you would encounter day to day as a DBA. That being said, one thing that is currently missing is the ability to easily add hints without changing code via stored_procedures / functions like in Oracle. The only way to currently do this in Open Source PostgreSQL is to manually manipulate a table named “hints” typically located in the “hint_plan” schema.
The “hints” table which is provided by the extension is highly dependent (just like Oracle) on a normalized SQL statement. A normalized SQL statement in PostgreSQL is one that has all carriage returns removed, all spaces converted to single spaces and all literals and parameters replaced with a “?”. Typically you have to do this manually, but in this blog post, I am going to show how I have leveraged entries in “pg_stat_statements” along with custom written functions to normalize the statement and place it into the “hints” table. To use this “hints” table feature, the following setting must be enabled at either the session or system level:
set session pg_hint_plan.enable_hint_table to on; or in the postgresql.conf: pg_hint_plan.enable_hint_table to on;
What Does a Normalized Statement Look Like?
Typically, when you receive code from a developer or even code that you work on yourself, you format it in order to to make it human readable and easier to interpret. For example, you might want your statement to look like this (notice the parameters / literals in the statement:
SELECT
b.bid,
sum(abalance)
FROM
pgbench_branches b
JOIN pgbench_accounts a ON (b.bid = a.bid)
WHERE
b.bid = 12345
AND a.aid BETWEEN 100 AND 200
GROUP BY
b.bid
ORDER BY
1;
Now to normalize the statement for use with the “hints” table it needs to look like this:
select b.bid, sum(abalance) from pgbench_branches b join pgbench_accounts a on (b.bid = a.bid) where b.bid = ? and a.aid between ? and ? group by b.bid order by 1;
You can either manually manipulate the statement to get it in this format do this or we can attempt to do it programmatically. I prefer as much as possible to let the system format it for me so I have written a few helper scripts to do this:
Helper Queries:
**** Feel free to utilize these functions, however they may contain errors or may not normalize all statements. They depend on the pg_stat_statements table and if the entire statement will not fit within the query field of that table, then these functions will not produce the correct output. I will also place them on my public github. If you find any errors or omissions, please let me know. ****
hint_plan.display_candidate_pg_hint_plan_queries
While you can easily select from the “hints” table on your own, this query will show what a normalized statement will look like before loading it to the table. You can leave the “p_query_id” parameter null to return all queries present in the pg_stat_statements in a normalized form or you can populate it with a valid “query_id” and it will return a single normalized statement:
CREATE OR REPLACE FUNCTION hint_plan.display_candidate_pg_hint_plan_queries(
p_query_id bigint default null
)
RETURNS TABLE(queryid bigint, norm_query_string text)
LANGUAGE 'plpgsql'
COST 100
VOLATILE PARALLEL UNSAFE
AS $BODY$
DECLARE
pg_stat_statements_exists boolean := false;
BEGIN
SELECT EXISTS (
SELECT FROM
information_schema.tables
WHERE
table_schema LIKE 'public' AND
table_type LIKE 'VIEW' AND
table_name = 'pg_stat_statements'
) INTO pg_stat_statements_exists;
IF pg_stat_statements_exists AND p_query_id is not null THEN
RETURN QUERY
SELECT pss.queryid,
substr(regexp_replace(
regexp_replace(
regexp_replace(
regexp_replace(
regexp_replace(pss.query, '\$\d+', '?', 'g'),
E'\r', ' ', 'g'),
E'\t', ' ', 'g'),
E'\n', ' ', 'g'),
'\s+', ' ', 'g') || ';',1,100)
FROM pg_stat_statements pss where pss.queryid = p_query_id;
ELSE
RETURN QUERY
SELECT pss.queryid,
substr(regexp_replace(
regexp_replace(
regexp_replace(
regexp_replace(
regexp_replace(pss.query, '\$\d+', '?', 'g'),
E'\r', ' ', 'g'),
E'\t', ' ', 'g'),
E'\n', ' ', 'g'),
'\s+', ' ', 'g') || ';',1,100)
FROM pg_stat_statements pss;
END IF;
END;
$BODY$;
If our candidate query was this:
select queryid, query from pg_stat_statements where queryid = -8949523101378282526;
queryid | query
----------------------+-----------------------------
-8949523101378282526 | select b.bid, sum(abalance)+
| from pgbench_branches b +
| join pgbench_accounts a +
| on (b.bid = a.bid) +
| where b.bid = $1 +
| group by b.bid +
| order by 1
(1 row)
The display function would return the following normalized query:
SELECT hint_plan.display_candidate_pg_hint_plan_queries(p_query_id => -8949523101378282526);
-[ RECORD 1 ]--------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------
display_candidate_pg_hint_plan_queries | (-8949523101378282526,"select b.bid, sum(abalance) from pgbench_branches b join pgbench_accounts a on (b.bid = a.bid) where b.bid = ? group by b.bid order by 1;")
You can then verify that the query is normalized properly and then move on toward using the next function to add the normalized query to the “hints” table.
hint_plan.add_stored_pg_hint_plan
Using the same query in the previous section, we will now add it to the “hints” table. This is where it is important to understand what hint you want to add.
CREATE OR REPLACE FUNCTION hint_plan.add_stored_pg_hint_plan(
p_query_id bigint,
p_hint_text text,
p_application_name text default ''
)
RETURNS varchar
LANGUAGE 'plpgsql'
COST 100
VOLATILE PARALLEL UNSAFE
AS $BODY$
-- p_hint_text can contain one or more hints either separated by a space or
-- a carriage return character. Examples include:
-- Space Separated: SeqScan(a) Parallel(a 0 hard)
-- ASCII CRLF Separated: SeqScan(a)'||chr(10)||'Parallel(a 0 hard)
-- Single Hint: SeqScan(a)
--
-- Escaped text does not work: /* E'SeqScan(a)\nParallel(a 0 hard)'
DECLARE
hint_id hint_plan.hints.id%TYPE;
normalized_query_text hint_plan.hints.norm_query_string%TYPE;
pg_stat_statements_exists boolean := false;
BEGIN
SELECT EXISTS (
SELECT FROM
information_schema.tables
WHERE
table_schema LIKE 'public' AND
table_type LIKE 'VIEW' AND
table_name = 'pg_stat_statements'
) INTO pg_stat_statements_exists;
IF NOT pg_stat_statements_exists THEN
RAISE NOTICE 'pg_stat_statements extension has not been loaded, exiting';
RETURN 'error';
ELSE
SELECT regexp_replace(
regexp_replace(
regexp_replace(
regexp_replace(
regexp_replace(query, '\$\d+', '?', 'g'),
E'\r', ' ', 'g'),
E'\t', ' ', 'g'),
E'\n', ' ', 'g'),
'\s+', ' ', 'g') || ';'
INTO normalized_query_text
FROM pg_stat_statements where queryid = p_query_id;
IF normalized_query_text IS NOT NULL THEN
INSERT INTO hint_plan.hints(norm_query_string, application_name, hints)
VALUES (normalized_query_text,
p_application_name,
p_hint_text
);
SELECT id into hint_id
FROM hint_plan.hints
WHERE norm_query_string = normalized_query_text;
RETURN cast(hint_id as text);
ELSE
RAISE NOTICE 'Query ID %q does not exist in pg_stat_statements', cast(p_query_id as text);
RETURN 'error';
END IF;
END IF;
END;
$BODY$;
Hint text contain one or more hints either separated by a space or a carriage return character. Examples include:
Escaped text does not work in the context of this function although this can be used if you are inserting manually to the “hints” table: E’SeqScan(a)\nParallel(a 0 hard)’
SELECT hint_plan.add_stored_pg_hint_plan(p_query_id => -8949523101378282526,
p_hint_text => 'SeqScan(a) Parallel(a 0 hard)',
p_application_name => '');
-[ RECORD 1 ]-----------+---
add_stored_pg_hint_plan | 28
Time: 40.889 ms
select * from hint_plan.hints where id = 28;
-[ RECORD 1 ]-----+------------------------------------------------------------------------------------------------------------------------------------------
id | 28
norm_query_string | select b.bid, sum(abalance) from pgbench_branches b join pgbench_accounts a on (b.bid = a.bid) where b.bid = ? group by b.bid order by 1;
application_name |
hints | SeqScan(a) Parallel(a 0 hard)
In the above example, we are forcing a serial sequential scan of the “pgbench_accounts”. We left the “application name” parameter empty so that the hint applies to any calling application.
hint_plan.delete_stored_pg_hint_plan
You could easily just issue a delete against the “hints” table, but in keeping with utilizing a “function” approach to utilizing this functionality, a delete helper has also been developed:
CREATE OR REPLACE FUNCTION hint_plan.delete_stored_pg_hint_plan(
p_hint_id bigint
)
RETURNS TABLE(id integer, norm_query_string text, application_name text, hints text)
LANGUAGE 'plpgsql'
COST 100
VOLATILE PARALLEL UNSAFE
AS $BODY$
BEGIN
RETURN QUERY
DELETE FROM hint_plan.hints h WHERE h.id = p_hint_id RETURNING *;
END;
$BODY$;
To delete a plan you can call the procedure as follows:
SELECT hint_plan.delete_stored_pg_hint_plan(p_hint_id => 28);
-[ RECORD 1 ]--------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
delete_stored_pg_hint_plan | (28,"select b.bid, sum(abalance) from pgbench_branches b join pgbench_accounts a on (b.bid = a.bid) where b.bid = ? group by b.bid order by 1;","","SeqScan(a) Parallel(a 0 hard)")
Time: 33.685 ms
select * from hint_plan.hints where id = 28;
(0 rows)
Time: 24.868 ms
As you can see the “hints” table is very useful and can help you emulate many parts of SQL Plan Management just like in Oracle.
As migrations to CloudSQL and AlloyDB pick up speed, inevitably you will run into a condition where the cloud tooling has not quite caught up with exposing custom alerts and incidents that you may be exposing on-premises with tools such as Nagios or Oracle Enterprise Manager. One such example is monitoring of replication tools such as the GoldenGate Heartbeat table. While there are many ways that you may be able to implement this, I wanted to demonstrate a way to leverage Google Cloud Logging + Google Cloud Monitoring. Using this method will allow us to keep a long term log of certain parameters like lag or anything else you have built into the heartbeat mechanism. To demonstrate, lets use Python to query the database and create a Cloud Logging Entry:
import argparse
from datetime import datetime, timedelta
from sqlalchemy import create_engine, text
from google.cloud import logging
def retrievePgAlert(
username: str,
password: str,
hostname: str,
portNumber: int,
databaseName: str,
alertType: str,
) -> None:
alertList: list = []
conn_string = f"postgresql+psycopg2://{username}:{password}@{hostname}:{portNumber}/{databaseName}?client_encoding=utf8"
engine = create_engine(conn_string)
with engine.connect() as con:
if alertType == "ogg-lag":
sqlQuery = text(
f"select replicat, effective_date, lag from ogg.heartbeat where lag >=:lagAmt and effective_date >= now() - interval ':intervalAmt min'"
)
result = con.execute(
sqlQuery, {"lagAmt": oggLagAmt, "intervalAmt": checkIntervalMinutes}
).fetchall()
for row in result:
alertList.append(row)
if not alertList:
print(f"No alerts as of {datetime.now().strftime('%m/%d/%Y %H:%M:%S')}")
else:
for alertText in alertList:
print(
f"Replicat: {alertText[0]} at date {alertText[1]} has a total lag of: {alertText[2]} seconds"
)
writeGcpCloudLoggingAlert(
logger_alert_type=alertType,
loggerName=args.loggerName,
logger_message=alertList,
)
con.close()
engine.dispose()
def writeGcpCloudLoggingAlert(
logger_alert_type: str,
loggerName: str,
logger_message: list,
) -> None:
# Writes log entries to the given logger.
logging_client = logging.Client()
# This log can be found in the Cloud Logging console under 'Custom Logs'.
logger = logging_client.logger(loggerName)
# Struct log. The struct can be any JSON-serializable dictionary.
if logger_alert_type == "ogg-lag":
replicatName: str
effectiveDate: datetime
lagAmount: str
for alertFields in logger_message:
replicatName = alertFields[0]
effectiveDate = alertFields[1]
lagAmount = int(alertFields[2])
logger.log_struct(
{
"alertType": logger_alert_type,
"replicat": str(alertFields[0]),
"alertDate": alertFields[1].strftime("%m/%d/%Y, %H:%M:%S"),
"alertRetrievalDate": datetime.now().strftime("%m/%d/%Y, %H:%M:%S"),
"lagInSeconds": int(alertFields[2]),
},
severity="ERROR",
)
print("Wrote logs to {}.".format(logger.name))
def delete_logger(loggerName):
"""Deletes a logger and all its entries.
Note that a deletion can take several minutes to take effect.
"""
logging_client = logging.Client()
logger = logging_client.logger(loggerName)
logger.delete()
print("Deleted all logging entries for {}".format(logger.name))
if __name__ == "__main__":
cloudSQLHost: str = "127.0.0.1"
hostname: str
portNumber: str
database: str
username: str
password: str
oggLagAmt: int = 15
checkIntervalMinutes: int = 20
with open("~/.pgpass", "r") as pgpassfile:
for line in pgpassfile:
if line.strip().split(":")[0] == cloudSQLHost:
hostname, portNumber, database, username, password = line.strip().split(
":"
)
parser = argparse.ArgumentParser(
description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter
)
parser.add_argument(
"-loggerName",
"--loggerName",
type=str,
help="GCP Cloud Log Namespace",
default="postgres-alert",
)
parser.add_argument(
"-alertType",
"--alertType",
type=str,
help="Type of alert to log",
default="ogg-lag",
)
args = parser.parse_args()
if args.alertType == "ogg-lag":
retrievePgAlert(
hostname=hostname,
username=username,
password=password,
portNumber=portNumber,
databaseName=database,
alertType=args.alertType,
)
In this script we utilize the Google Cloud Logging APIs, SQLAlchemy and some other basic python imports to query the database based on a lag amount we are looking for from the heartbeat table.
***Note: The query within the python code could check for any condition by changing the query, by leveraging “gcloud” commands or REST API calls.
If the condition is met, the script creates a JSON message which is then written to the appropriate Google Cloud Logging Namespace. An example of the JSON message is below (sensitive information like the project id and instance id have been redacted):
Now that we have published a message to Cloud Logging, what can we do with it? Generally there are two paths, either a Cloud Metric or a Cloud Alert. For this demonstration, we will use the “Cloud Alert”. So to start the setup navigate to the console page “Operations Logging” —> “Logs Explorer”. From there click the “Create alert” function. The following dialog will show. You will need to double check the query to retrieve the appropriate logs in step 2, and in step 3, you can choose the time between notifications (this is to mute alerts that happen in between the interval) and how long past the last alert an incident will stay open. In this case, we will mute duplicate alerts that happen for 5 minutes after the first alert (if an alert occurs at 6 minutes another notification will fire) and incidents will remain open for 30 minutes past the last alert (no new incidents will be logged unless an alert occurs after that time frame). The query to be used within the alert is as follows:
logName="projects/[project id]/logs/postgres-alert"
AND severity="ERROR"
AND (jsonPayload.alertType = "ogg-lag")
AND (jsonPayload.lagInSeconds >= 15)
AND resource.labels.instance_id = [instance id]
The following dialogues outline the screens used to setup the alert.
The last step will be to choose your notification method, which is managed by different notification channels. The different types of notification channels include:
Mobile Devices
PagerDuty Services
PagerDuty Sync
Slack
Webhooks
E-Mail
SMS
Pub/Sub
Once all of this is defined, your alert is now set to notify once you place the python script on an appropriate schedule such as linux cron, Google Cloud Scheduler, etc. In this case we will now wait for an issue to occur that conforms to the alert. When it does an email like the following will result to the notification channel:
As your migration to cloud continues, keep an open mind and look for alternative ways to handle all of the operational “things” you are accustomed to in your on-premises environment. Most of the time there is a way in cloud to handle it!
In my previous post “Three Configuration Parameters for PostgreSQL That Are Worth Further Investigation!“, I introduced three PostgreSQL parameters that I feel are the most “neglected” and present the most opportunity for performance tuning in a PostgreSQL instance. I’ve previously posted parts 1 and 2 which cover “work_mem” and “effective_io_concurrency“, so in the final part of this series, I would like to demonstrate tuning the “random_page_cost” parameter.
Because PostgreSQL has the ability to be installed on many different types of systems, the default for this parameter represents a system that is likely the least performant, one that has low CPU and a disk subsystem that is less than ideal. This setting can be overridden at the individual object level as well, however that may represent a management nightmare so I would recommend against that. A good explanation of the parameter exists here, and for most CloudSQL instances, should likely be set lower than the default because random page costs are expected to be less expensive on the types of I/O subsystems are present within today’s cloud environments.
For those of you that come from Oracle backgrounds, this parameter is very much like the “OPTIMIZER_INDEX_COST_ADJ” parameter that we used to manipulate in older Oracle versions. To refresh your mind on this parameter you can see the 19c explanation here.
As a simple example of how the query plan can change for a simple SQL, I will first show the query plan with the default setting of 4. While it is using an index, the access path could be better:
set max_parallel_workers_per_gather = 0;
set session random_page_cost to 4;
explain (analyze, verbose, costs, settings, buffers, wal, timing, summary, format text)
SELECT c.c_name, c.c_acctbal, sum(o.o_totalprice)
FROM orders o
JOIN customer c ON (c.c_custkey = o.o_custkey)
WHERE c.c_custkey = 30003 and o.o_orderstatus = 'O'
GROUP BY c.c_name, c.c_acctbal;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
GroupAggregate (cost=76.28..76.37 rows=1 width=57) (actual time=0.034..0.035 rows=0 loops=1)
Output: c.c_name, c.c_acctbal, sum(o.o_totalprice)
Group Key: c.c_name, c.c_acctbal
Buffers: shared hit=7
-> Sort (cost=76.28..76.30 rows=8 width=33) (actual time=0.033..0.034 rows=0 loops=1)
Output: c.c_name, c.c_acctbal, o.o_totalprice
Sort Key: c.c_name, c.c_acctbal
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=7
-> Nested Loop (cost=4.97..76.16 rows=8 width=33) (actual time=0.027..0.028 rows=0 loops=1)
Output: c.c_name, c.c_acctbal, o.o_totalprice
Buffers: shared hit=7
-> Index Scan using customer_pk on public.customer c (cost=0.42..8.44 rows=1 width=31) (actual time=0.014..0.015 rows=1 loops=1)
Output: c.c_custkey, c.c_mktsegment, c.c_nationkey, c.c_name, c.c_address, c.c_phone, c.c_acctbal, c.c_comment
Index Cond: (c.c_custkey = '30003'::numeric)
Buffers: shared hit=4
-> Bitmap Heap Scan on public.orders o (cost=4.55..67.64 rows=8 width=14) (actual time=0.009..0.009 rows=0 loops=1)
Output: o.o_orderdate, o.o_orderkey, o.o_custkey, o.o_orderpriority, o.o_shippriority, o.o_clerk, o.o_orderstatus, o.o_totalprice, o.o_comment
Recheck Cond: (o.o_custkey = '30003'::numeric)
Filter: (o.o_orderstatus = 'O'::bpchar)
Buffers: shared hit=3
-> Bitmap Index Scan on order_customer_fkidx (cost=0.00..4.55 rows=16 width=0) (actual time=0.008..0.008 rows=0 loops=1)
Index Cond: (o.o_custkey = '30003'::numeric)
Buffers: shared hit=3
Settings: effective_cache_size = '3053008kB', effective_io_concurrency = '10', max_parallel_workers_per_gather = '0', work_mem = '512MB'
Query Identifier: 7272380376793434809
Planning:
Buffers: shared hit=2
Planning Time: 0.234 ms
Execution Time: 0.076 ms
And now with a change to a setting of 2, we get a different access path:
set max_parallel_workers_per_gather = 0;
set session random_page_cost to 2;
explain (analyze, verbose, costs, settings, buffers, wal, timing, summary, format text)
SELECT c.c_name, c.c_acctbal, sum(o.o_totalprice)
FROM orders o
JOIN customer c ON (c.c_custkey = o.o_custkey)
WHERE c.c_custkey = 30003 and o.o_orderstatus = 'O'
GROUP BY c.c_name, c.c_acctbal;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
GroupAggregate (cost=39.38..39.48 rows=1 width=57) (actual time=0.027..0.028 rows=0 loops=1)
Output: c.c_name, c.c_acctbal, sum(o.o_totalprice)
Group Key: c.c_name, c.c_acctbal
Buffers: shared hit=7
-> Sort (cost=39.38..39.40 rows=8 width=33) (actual time=0.026..0.027 rows=0 loops=1)
Output: c.c_name, c.c_acctbal, o.o_totalprice
Sort Key: c.c_name, c.c_acctbal
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=7
-> Nested Loop (cost=0.85..39.26 rows=8 width=33) (actual time=0.021..0.022 rows=0 loops=1)
Output: c.c_name, c.c_acctbal, o.o_totalprice
Buffers: shared hit=7
-> Index Scan using customer_pk on public.customer c (cost=0.42..4.44 rows=1 width=31) (actual time=0.012..0.012 rows=1 loops=1)
Output: c.c_custkey, c.c_mktsegment, c.c_nationkey, c.c_name, c.c_address, c.c_phone, c.c_acctbal, c.c_comment
Index Cond: (c.c_custkey = '30003'::numeric)
Buffers: shared hit=4
-> Index Scan using order_customer_fkidx on public.orders o (cost=0.43..34.75 rows=8 width=14) (actual time=0.008..0.008 rows=0 loops=1)
Output: o.o_orderdate, o.o_orderkey, o.o_custkey, o.o_orderpriority, o.o_shippriority, o.o_clerk, o.o_orderstatus, o.o_totalprice, o.o_comment
Index Cond: (o.o_custkey = '30003'::numeric)
Filter: (o.o_orderstatus = 'O'::bpchar)
Buffers: shared hit=3
Settings: effective_cache_size = '3053008kB', effective_io_concurrency = '10', max_parallel_workers_per_gather = '0', random_page_cost = '2', work_mem = '512MB'
Query Identifier: 7272380376793434809
Planning:
Buffers: shared hit=2
Planning Time: 0.199 ms
Execution Time: 0.064 ms
Now, for this simple example, the execution time isn’t vastly different, because in both cases an index is being used, however, in cases where the parameter adjustment allows an index to be used over a sequential scan, you will really see the benefit.
Ultimately, there are some other parameters that may benefit from adjustment such as the “cpu_*” parameters, however, those will require much more testing and experimentation over the adjustment of “random_page_cost” especially if your system is running SSDs as in most Google CloudSQL for Postgres instances or even Google AlloyDB where the I/O subsystem is built specifically for the implementation. And if you use either of these implementations, I would highly consider updating this parameter from the default of 4 to at least 2, maybe even 1.1 depending on the shape that you have chosen and the I/O limits served by each Shape.
In my previous post “Three Configuration Parameters for PostgreSQL That Are Worth Further Investigation!“, I introduced three PostgreSQL parameters that I feel are the most “neglected” and present the most opportunity for performance tuning in a PostgreSQL instance. I’ve previously discussed “work_mem” in a previous post, so in Part 2 of this series, I would like to demonstrate tuning the “effective_io_concurrency” parameter. While this parameter has been discussed in other blogs, I will attempt to make this discussion relevant to how it might affect a CloudSQL instance.
The parameter “effective_io_concurrency” reflects the number of simultaneous requests that can be handled efficiently by the disk subsystem. One thing to keep in mind is that currently this parameter only effects “bitmap_heap_scans” where the data is not already present in the shared buffer. In general, if using spinning HDD devices, this should be set to reflect the number of drives that participate in the RAID stripe. In cases where SSDs are used, you can set this value much higher, although you must take into account any Quality of Service I/O ops limits which are usually present in a cloud implementation. A full explanation of the parameter can be found here.
To do a simple demonstration of how this parameter can effect queries, I set up a small Google CloudSQL for Postgres instance (2 vCPU X 8GB memory) and loaded up some tables, then executed a query that ensured a “bitmap heap scan” changing “effective_io_concurrency” parameter between each test. In addition, the instance was bounced before each test to ensure that the shared buffers were cleared.
Setup:
CREATE TABLE public.effective_io_concurrency_test (
id int PRIMARY KEY,
value numeric,
product_id int,
effective_date timestamp(3)
);
INSERT INTO public.effective_io_concurrency_test VALUES (
generate_series(0,100000000),
random()*1000,
random()*100,
current_timestamp(3));
CREATE INDEX prod_id_idx ON public.effective_io_concurrency_test (product_id);
VACUUM ANALYZE public.effective_io_concurrency_test;
Execution:
The resulting query plans did not show any variation in execution path or cost, but the timings did vary across the tests.
EXPLAIN (analyze, verbose, costs, settings, buffers, wal, timing, summary, format text)
SELECT * FROM public.effective_io_concurrency_test
WHERE id BETWEEN 10000 AND 100000;
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on public.effective_io_concurrency_test (cost=7035.15..522009.95 rows=547023 width=27) (actual time=293.542..33257.631 rows=588784 loops=1)
Output: id, value, product_id, effective_date
Recheck Cond: (((effective_io_concurrency_test.id >= 10000) AND (effective_io_concurrency_test.id = 100) AND (effective_io_concurrency_test.product_id BitmapOr (cost=7035.15..7035.15 rows=547450 width=0) (actual time=156.951..156.954 rows=0 loops=1)
Buffers: shared hit=6 read=668
I/O Timings: read=24.501
-> Bitmap Index Scan on effective_io_concurrency_test_pkey (cost=0.00..1459.74 rows=94117 width=0) (actual time=14.908..14.908 rows=90001 loops=1)
Index Cond: ((effective_io_concurrency_test.id >= 10000) AND (effective_io_concurrency_test.id Bitmap Index Scan on prod_id_idx (cost=0.00..5301.90 rows=453333 width=0) (actual time=142.040..142.040 rows=499255 loops=1)
Index Cond: ((effective_io_concurrency_test.product_id >= 100) AND (effective_io_concurrency_test.product_id <= 200))
Buffers: shared hit=3 read=421
I/O Timings: read=14.154
Settings: effective_cache_size = '3259448kB', effective_io_concurrency = '8', random_page_cost = '2', work_mem = '512MB'
Query Identifier: -8974663893066369302
Planning:
Buffers: shared hit=103 read=17
I/O Timings: read=26.880
Planning Time: 28.350 ms
Execution Time: 33322.389 ms
Summary:
effective_io_concurrency
Query Time
1 /* CloudSQL Default */
194708.918 ms
2 /* Equal number of CPU */
107953.205 ms
4 /* 2x number of CPU */
58161.010 ms
8 /* 4x number of CPU */
33322.389 ms
10 /* 5x number of CPU */
30118.593 ms
20 /* 6x number of CPU */
28758.106 ms
As you can see, there is a diminishing return as we increased the parameter, but why? Upon looking at Google Cloud Console “System Insights” the reason was clear.
**** One thing to note, is that the CPU Utilization spike is a result of the shutdown and restart of the instance between each test. The utilization following the spike represents the utilization found during the test itself.
The Conclusion:
While CPU utilization didn’t hit any limit, the IOPS limits for that CloudSQL shape did. You can add IOPS by changing the shape, but the point of this was to show that the optimal setting always depends on your workload and instance shape. In this case and for this CloudSQL shape, you might actually want to choose a setting of “4” which represents a setting of 2x the number of CPU and one that doesn’t quite max out the guaranteed IOPS. The setting doesn’t get you the fastest query time, but does leave resources left over for other queries to execute at the same time.
As always, be sure to test any changed in your own system and balance accordingly because your “mileage may vary” depending on your individual situation. That being said, in almost no cases is the default setting acceptable unless you are running HDD or on an OS which lacks “posix_fadvise” function (like MacOS or Solaris).
In my new role at Google, not only am I still working with lots of Oracle and replication tools, I am also expanding more into moving Oracle systems to Google Cloud on either CloudSQL for PostgreSQL or AlloyDB for PostgreSQL. After you have been looking at the systems for a little bit of time, there seem to be a few things worth tweaking from the out of the box values. It is my goal to discuss some of those things now and in future blog posts.
Let me start off by saying managed PostgreSQL CloudSQL products such as Google’s CloudSQL for PostgreSQL and AlloyDB for PostgreSQL (in Preview as of this post) are designed to be low maintenance and fit many different types of workloads. That being said, there are a few configuration parameters that you should really look at tuning as the defaults (as of PostgreSQL version 14) in most cases are just not set to the most efficient value if your workload is anything more than a VERY light workload.
work_mem
Sets the base maximum amount of memory to be used by a query operation (such as a sort or hash table) before writing to temporary disk files and the default value is four megabytes (4MB). People coming from the Oracle world will equate this setting with PGA, however you must keep in mind that the implementation is “private” memory in PostgreSQL while it is “shared” memory in Oracle. You must take care not to over configure this setting in PostgreSQL.
A full description of the parameter can be found here.
random_page_cost
Sets the planner’s estimate of the cost of a non-sequentially-fetched disk page and the default is 4.0. In reality this setting is good for a system in which disk performance is a concern (i.e a system with HDD vs SSDs) as it is assumed that random disk access is 40x slower than sequential access. Essentially if you want your system to prefer index and cache reads, lower this number from the default, but to no lower than the setting for seq_page_cost. For normal CloudSQL for PostgreSQL deployments that use SSD, I like to set this to 2. In deployments which utilize AlloyDB for PostgreSQL an even lower setting of 1.1 can be used due to the efficient Colossus Storage implementation.
For those that have been around Oracle for a while, this parameter behaves much like the “optimizer_index_cost_adj” parameter.
A full description of the parameter can be found here.
effective_io_concurrency
Sets the number of concurrent disk I/O operations that PostgreSQL expects can be executed simultaneously. Raising this value will increase the number of I/O operations that any individual PostgreSQL session attempts to initiate in parallel. The default is 1 and at this point this setting only effects bitmap heap scans. That being said, bitmap heap scans, while efficient, by nature have to look at the index as well as a corresponding heap block and if that data has to be read from disk and if your system can handle the parallelism like when you use SSD storage, you should increase this to a more meaningful value. I will do a separate blog post to show the effects of this, but in general as this number is increased beyond 1/2 the number of CPUs available, greater diminishing returns are observed.
A full description of the parameter can be found here.
In closing, just like Oracle and other RDBMSs, there are numerous configuration parameters all which can have effects on the workload. However, the above three parameters are the ones I most often find that have opportunities for optimization, especially on more modern platforms.
In future posts I will detail how each one of these can change a workload.