Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity

From: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity
Date: 2022-06-21 20:04:01
Message-ID: 516E294A-A0EC-4998-9C3C-BBFCA6E679A5@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Good point. I will separate this patch.

I separated the pg_stat_statements patch. The patch
Introduces a secondary hash that tracks locations of
A query ( by queryid ) in the external file. The hash
remains in lockstep with the pgss_hash using a
synchronization routine. For the default
pg_stat_statements.max = 5000, this hash requires 2MB megabytes
of additional shared memory.

My testing does not show any regression for workloads
In which statements are not issues by multiple users/databases.

However, it shows good improvement, 10-15%, when there
are similar statements that are issues by multiple
users/databases/tracking levels.

Besides this improvement, this will open up the opportunity
to also track plan_id's as discussed earlier in the thread.

Thanks for the feedback.

Regards,

Sami Imseih
Amazon Web Services

Attachment Content-Type Size
0001-Improve-pg_stat_statements-performance-for-similar-q.patch application/octet-stream 13.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2022-06-21 20:24:14 Re: Schema variables - new implementation for Postgres 15
Previous Message Pavel Borisov 2022-06-21 17:52:56 Re: Use fadvise in wal replay