> in the read cycle. In addition to our case with large PGSS_TEXT_FILE (and
> maybe the problems with virtual disk i/o) that can explain uncancellable
> pg_stat_statements queries.
I'm afraid it might be not so easy to add CHECK_FOR_INTERRUPTS there. Most
probably you was holding a
ancellable pg_stat_statements queries. Also, the reading block size can be reduced from 1GB to 32MB in order to increase the frequency of CHECK_FOR_INTERRUPTS calls without qtext_load_file performance degradation. To check that I did some little testing with fio like: fio --name=readtest --filename=./random-bytes
e explain, and we
may not even need it at all since generic plans
are already displayed with $1, $2 parameters.
Let me know if you have other comments for v5, the
pg_stat_statements enhancements.
—
Sami Imseih
Amazon Web Services (AWS)
rebased in the attached v5.
--
Sami Imseih
Amazon Web Services (AWS)
v5-0001-Add-plan_cache-counters-to-pg_stat_statements.patch
Description: Binary data
Since at the moment these changes are not a priority, and it's more
important to address [0] for pg_stat_statements, I'm marking this patch
as "Returned with Feedback".
[0]: https://www.postgresql.org/message-id/Zz0MFPq1s4WFxxpL%40paquier.xyz
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
After the introduction of pg_overexplain extension and Robert's comment
[0], I'm starting to have doubts about whether it's still appropriate to
add this information to EXPLAIN itself. If there are compelling reasons
that showing the plan type would be broadly useful to users in EXPLAIN,
I’m ha
Hi!
Thank you for detailed explanations.
Respectfully,
Mikhail Litsarev,
Postgres Professional: https://postgrespro.com
Hi,
I attached rebased patch v20.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From accee46b077e1debdc3db61555923b2c11e18d5e Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Fri, 21 Mar 2025 17:37:08 +0300
Subject: [PATCH v20] Allow setting sample rate for pg_stat_statements
New
m.litsa...@postgrespro.ru writes:
>> What does this patch give on aglobal scale? Does it save much memory or
>> increase performance? How many times?
> This patch makes the code semantically more correct and we don't lose
> anything. It is obviously not about performance or memory optimisation.
> Sure, it's important and I'm planning to tackle this next. If you want,
> we can collaborate on a patch for that.
I spent some time looking some more at this, and I believe all that needs
to be done is check for a PRAM node with a type of PARAM_EXTERN.
During planning the planner turns the Para
> On Tue, Mar 18, 2025 at 02:54:18PM GMT, Sami Imseih wrote:
> I want to mention that the current patch does not deal
> with external parameters ( prepared statements ) [0] [1]. This could be a
> follow-up, as it may need some further discussion. It is important to
> address this case, IMO.
Sure,
> On Tue, Mar 18, 2025 at 07:33:25PM GMT, Álvaro Herrera wrote:
>
> By the way, I'm still open to adding the 'powers' mechanism that was
> discussed earlier and other simple additions on top of what's there now,
> if you have some spare energy to spend on this. (For full disclosure:
> the "powers"
On 2025-Mar-18, Sami Imseih wrote:
> I want to mention that the current patch does not deal
> with external parameters ( prepared statements ) [0] [1]. This could be a
> follow-up, as it may need some further discussion. It is important to
> address this case, IMO.
Yes, I realize that. Feel free
st that has zero elements.
Anyway, something to play with.
BTW, it's fun to execute a query that's literally
select col from tab where col in (1 /*, ... */);
and then
select col from tab where col in (1, 2);
because now you have two entries in pg_stat_statements with visibly the
same quer
I want to mention that the current patch does not deal
with external parameters ( prepared statements ) [0] [1]. This could be a
follow-up, as it may need some further discussion. It is important to
address this case, IMO.
[0]
https://www.postgresql.org/message-id/CAA5RZ0uGfxXyzhp9N5nfsS%2BZqF5ng
> On Mon, Mar 17, 2025 at 08:14:16PM GMT, Álvaro Herrera wrote:
> On 2025-Mar-17, Álvaro Herrera wrote:
>
> > You can see my patch on top of yours here:
> > https://github.com/alvherre/postgres/commits/query_id_squash_values/
> > and the CI run here:
> > https://cirrus-ci.com/build/5660053472018432
On 2025-Mar-17, Álvaro Herrera wrote:
> You can see my patch on top of yours here:
> https://github.com/alvherre/postgres/commits/query_id_squash_values/
> and the CI run here:
> https://cirrus-ci.com/build/5660053472018432
Heh, this blew up on bogus SGML markup :-( Fixed and running again:
http
data
++--
+(0 rows)
+
+SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C";
+ query| calls
++---
+ SELECT * FROM test_squash_cast WHERE data IN +| 1
+
On Mon, 17 Mar 2025 at 13:42, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Mar 17, 2025 at 12:07:44PM GMT, vignesh C wrote:
> >
> > I noticed that the feedback from Sami at [1] has not yet been
> > addressed, I have changed the status to Waiting on Author, kindly
> > address them and
On 2025-Mar-17, Dmitry Dolgov wrote:
> I'm afraid there is a disagreement about this part of the feedback. I'm
> not yet convinced about the idea suggested over there (treating mutable
> functions in the same way as constants) and not planning to change
> anything, at least not in the current vers
> On Mon, Mar 17, 2025 at 12:07:44PM GMT, vignesh C wrote:
>
> I noticed that the feedback from Sami at [1] has not yet been
> addressed, I have changed the status to Waiting on Author, kindly
> address them and update the status to Needs review.
> [1] -
> https://www.postgresql.org/message-id/CAA
On Mon, 3 Mar 2025 at 17:26, Álvaro Herrera wrote:
>
> On 2025-Feb-18, Sami Imseih wrote:
>
> > > It's not a question about whether it's possible to implement this,
> > > but about whether it makes sense. In case of plain constants it's
> > > straightforward -- they will not change anything meanin
> Thank you for your patch. It is really useful for tracking the history
> of generic and custom plan usage.
Thanks for the review!
> 1. Is there any reason for the double check of cplan != NULL? It seems
> unnecessary, and we could simplify it to:
>
> -if (cplan && cplan->status == PLAN_CACHE_ST
> I don't quite understand why do we need to differentiate between
> PLAN_CACHE_STATUS_GENERIC_PLAN_BUILD and
> PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE?
> We could simply keep PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE.
> I don't think users would see much of a difference in either
to differentiate between
PLAN_CACHE_STATUS_GENERIC_PLAN_BUILD and
PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE? We could simply keep
PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE. I don't think users would see much
of a difference in either pg_stat_statements or EXPLAIN.
As for EXPLAIN, maybe we should include this in VERBOSE mode?
-
Hi,
Thank you for your patch. It is really useful for tracking the history
of generic and custom plan usage.
At first glance, I have the following suggestions for improvement:
1. Is there any reason for the double check of cplan != NULL? It seems
unnecessary, and we could simplify it to:
-
>
> Please see v2
>
oops, had to fix a typo in meson.build. Please see v3.
--
Sami
v3-0001-add-plan_cache-counters-to-pg_stat_statements.patch
Description: Binary data
trong feelings about this.
> FILE: contrib/pg_stat_statements/expected/plan_cache.out
>
> These tests seem very verbose. Why not just prepare a simple query:
>
> prepare foo as select $1 > 0;
> execute foo(1);
> ...then tweak things via plan_cache_mode to ensure we test the ri
being somewhat useful (especially for non-interactive
things like auto_explain), so a weak +1 on that.
Definitely not useful for pg_stat_database IMHO.
Some quick comments on the patch:
FILE: contrib/pg_stat_statements/expected/plan_cache.out
These tests seem very verbose. Why not just prepare a
information cumulatively and over time. [0] had intentions
to add these counters to pg_stat_statements, but was withdrawn due
to timing with the commitfest at the time [0] and never picked back up again.
I think it's useful to add these counters.
Therefore, the attached patch adds two new colum
> > > It's not a question about whether it's possible to implement this,
> > > but about whether it makes sense. In case of plain constants it's
> > > straightforward -- they will not change anything meaningfully and
> > > hence could be squashed from the query. Now for a function, that
> > > might
> On Mon, Mar 03, 2025 at 12:56:24PM GMT, Álvaro Herrera wrote:
> In the meantime, here's v28 which is Dmitry's v27 plus pgindent. No
> other changes. Dmitry, were you planning to submit a new version?
Nope, there was nothing I wanted to add so far.
On 20.02.2025 04:04, Sami Imseih wrote:
In my opinion, sample rate is a better fit for pg_stat_statements,
since the queries that
you care about the most are usually the most frequently executed. Sampling them
will still provide enough good data without the risk of not capturing
statistics
5e8d7a960ebaf12e1a5798fb1a8941b55771fcc Mon Sep 17 00:00:00 2001
From: Dmitrii Dolgov <9erthali...@gmail.com>
Date: Tue, 3 Dec 2024 14:55:45 +0100
Subject: [PATCH v28] Prevent jumbling of every element in ArrayExpr
pg_stat_statements produces multiple entries for queries like
SELECT
On 20.02.2025 03:32, Sami Imseih wrote:
As you can see, the query has not been normalized. Is it a bug, expected or
undefined behavior?
No, this behavior is expected. The ability to normalize a statement is
only available
during post_parse_analyze (pgss_post_parse_analyze), as this is when
we
>
> Well sure, but best effort is better than no effort at all. Preventing
> CREATE/ALTER will catch 99% of items, and as I advocated, there really is no
> reason for them to be in pg_stat_statements in the first place.
>
>>
>> The clients that set passwords could si
On Tue, Feb 25, 2025 at 10:12 AM Sami Imseih wrote:
> > What about a more general solution, such as a flag to turn off logging
> of ALTER ROLE statements completely?
>
> IMO, flags for a specific type of utility statement seems way too much for
> pg_stat_statements, and
Sami Imseih writes:
>> What about a more general solution, such as a flag to turn off logging of
>> ALTER ROLE statements completely?
> IMO, flags for a specific type of utility statement seems way too much
> for pg_stat_statements, and this will also not completely prevent le
> What about a more general solution, such as a flag to turn off logging of
> ALTER ROLE statements completely?
IMO, flags for a specific type of utility statement seems way too much
for pg_stat_statements, and this will also not completely prevent leaking
plain text passwords from all way
What about a more general solution, such as a flag to turn off logging of
ALTER ROLE statements completely? Does anyone really need to know the
standard deviation of the timings for "ALTER ROLE alice SET
work_mem='50MB'"? Let's be honest, there are a lot of things that g
On 2025-02-24 Mo 11:04 AM, Peter Eisentraut wrote:
On 21.02.25 17:38, Andrew Dunstan wrote:
I don't think this is such a terrible kluge. I think it's different
from the server log case, which after all requires access to the
server file system to exploit.
To me, the mechanism by which this
Thanks for all the comments on this folks! I probably underestimated
this change.
Thanks all.
--
Matheus Alcantara
On 21.02.25 17:38, Andrew Dunstan wrote:
I don't think this is such a terrible kluge. I think it's different from
the server log case, which after all requires access to the server file
system to exploit.
To me, the mechanism by which this patch works is completely nonobvious
and coincidental
Matheus Alcantara writes:
> Attached a patch to redact the password value from pg_stat_statements_view
> when
> executing:
> { CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED]
> PASSWORD 'value' }
Please see previous threads about hiding this sort of information,
most recently [1
d kluges.
> I don't think this is such a terrible kluge. I think it's different from
> the server log case, which after all requires access to the server file
> system to exploit.
Well, pg_stat_statements requires pg_read_all_stats membership before
it will show you query text, so
Greg Sabino Mullane writes:
> I'm wondering what else we can do to discourage this pattern, however.
> There are more secure ways to set/change a password, but we keep seeing
> plain text pop up in various contexts. Maybe a strong warning+hint when
> someone uses these commands? A future GUC to di
On 2025-02-21 Fr 11:08 AM, Tom Lane wrote:
Matheus Alcantara writes:
Attached a patch to redact the password value from pg_stat_statements_view when
executing:
{ CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED]
PASSWORD 'value' }
Please see previous threads about hiding this
> It's a slippery slope for which there are no
> real fixes, and even partial fixes like this one are horrid kluges.
+1,
For example I don't think the current patch can deal with passwords
set in ALTER/CREATE inside DO blocks, and there is probably not
a sensible way to deal with that either.
Re
The idea and the patch looks good to me at first glance, +1.
I'm wondering what else we can do to discourage this pattern, however.
There are more secure ways to set/change a password, but we keep seeing
plain text pop up in various contexts. Maybe a strong warning+hint when
someone uses these com
Hi hackers!
Attached a patch to redact the password value from pg_stat_statements_view when
executing:
{ CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED]
PASSWORD 'value' }
To redact the password from the pg_stat_statements view a new field location
was added on String
> But instead of blindly reducing the frequency via PRNG, we can take a more
> thoughtful approach with threshold by execute time:
> Find the most frequent query by column 'calls' in pg_stat_statements;
> In this query look at info about execution time: min_exec_time,
> As you can see, the query has not been normalized. Is it a bug, expected or
> undefined behavior?
No, this behavior is expected. The ability to normalize a statement is
only available
during post_parse_analyze (pgss_post_parse_analyze), as this is when
we have access to
JumbleState.
In your ex
uce the load on the
spin-lock in pg_stat_statements.
If we look at the benchmark with 192 CPUs [0], we can see that even a
small reduction in the frequency of incrementing counter of entries
gives a significant performance boost. For example, at sample_rate =
0.75, performance almost do
I don't see v18 attached.
But, I think it's wrong that you changed the design of this patch
(sample rate to duration based ) after it was ready for committer.
This CF [0] should go back to "Needs Review" if this is the case.
--
Sami
[0] https://commitfest.postgresql.org/patch/5390/
On 14.02.2025 16:17, Ilia Evdokimov wrote:
Hi hackers,
I've decided to explore a slightly different approach to reducing
spinlock contention—by introducing a simple execution time threshold.
If a query’s execution time exceeds this threshold, it is recorded in
pg_stat_statements; othe
On Tue, Feb 18, 2025 at 08:48:43AM -0600, Sami Imseih wrote:
>> Btw, if you would like to share a code delta, please do not post it as a
>> patch or diff. This hijacks the CI pipeline, because CFbot thinks that's
>> a new version of the original patch.
>
> You're right. Sorry about that.
Exchangi
> > > This test was to catch a crash that was happening in older version of
> > > the patch, so it doesn't have to verify the actual pgss entry.
> >
> > It seems odd to keep this test because of crash behavior experienced
> > in a previous version of the patch. if the crash reason was understood
>
> On Mon, Feb 17, 2025 at 01:50:00PM GMT, Sami Imseih wrote:
> > This test was to catch a crash that was happening in older version of
> > the patch, so it doesn't have to verify the actual pgss entry.
>
> It seems odd to keep this test because of crash behavior experienced
> in a previous version
> This test was to catch a crash that was happening in older version of
> the patch, so it doesn't have to verify the actual pgss entry.
It seems odd to keep this test because of crash behavior experienced
in a previous version of the patch. if the crash reason was understood
and resolved, why kee
> On Mon, Feb 17, 2025 at 09:51:32AM GMT, Sami Imseih wrote:
> > This should do it. The last patch for today,
>
> I looked at v27 today and have a few comments.
>
> 1/ It looks like the CTE test is missing a check for results.
This test was to catch a crash that was happening in older version of
t
> This should do it. The last patch for today,
I looked at v27 today and have a few comments.
1/ It looks like the CTE test is missing a check for results.
"""
-- Test constants evaluation in a CTE, which was causing issues in the past
WITH cte AS (
SELECT 'const' as const FROM test_merge
)
SELE
On 14.02.2025 16:17, Ilia Evdokimov wrote:
Hi hackers,
I've decided to explore a slightly different approach to reducing
spinlock contention—by introducing a simple execution time threshold.
If a query’s execution time exceeds this threshold, it is recorded in
pg_stat_statements; othe
re 1 in ($1, $2, $3, $4) \bind 1 2 3 4
;
-- mixed constants and parameters
select where 1 in ($1, $2, $3, 4) \bind 1 2 3
;
select where 1 in ($1, $2, $3, 4, $4) \bind 1 2 3 5
;
select query, queryid, calls from pg_stat_statements;
postgres=# select query, queryid, calls from pg_stat_statements;
ith this issue is not so much the size of the query text,
> but it's the fact that similar queries ( with varying length IN-lists ) being
> tracked in different entries, causing high deallocation and heavy
> garbage collection. This is besides the overall loss of quality of
> the dat
ies ( with varying length IN-lists ) being
tracked in different entries, causing high deallocation and heavy
garbage collection. This is besides the overall loss of quality of
the data from pg_stat_statements if there is constant deallocation.
But, with what you are doing with this patch, we will now h
> On Fri, Feb 14, 2025 at 09:06:24AM GMT, Sami Imseih wrote:
> I think it will be sad to not include this very common case from
> the start, because it is going to be one of the most common
> cases.
>
> Wouldn't doing something like this inside IsMergeableConst
> """
> if (!IsA(arg, Const) && !IsA(
t;
Date: Tue, 3 Dec 2024 14:55:45 +0100
Subject: [PATCH v27] Prevent jumbling of every element in ArrayExpr
pg_stat_statements produces multiple entries for queries like
SELECT something FROM table WHERE col IN (1, 2, 3, ...)
depending on the number of parameters, because every element of
A
s.max, they the only choice might be to enable the new merging
parameter or deactivating pg_stat_statements.
> Or do you have some
> particular scenario of what might be problematic?
I don't have a very specific scenario. It's mostly for things like trying to
"un-jumble"
ble function for
> ArrayExpr).
OK. I don't necessarily agree with this, but it's been discussed [1] and
I will not push this point any further.
> > It's not a functionality regression as far as query execution
> > or pg_stat_statements counters go, but it is a reg
> On Fri, Feb 14, 2025 at 10:39:45PM GMT, Julien Rouhaud wrote:
> There seems to be an off-by-1 error in parameter numbering when merging them.
There are indeed three constants, but the second is not visible in the
query text. Maybe makes sense to adjust the number in this case, let me
try.
> Not
gt; +
> +SELECT * FROM test_merge WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11) AND
> data = 2;
> + id | data
> ++--
> +(0 rows)
> +
> +SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE
l, there are plenty expression nodes that have lists in them, maybe
more will be added in the future. And as before, the idea of using
pg_node_attr was a resonable suggestion from Michael Paquier on top of
the original design (which indeed used custom jumble function for
ArrayExpr).
Hi hackers,
I've decided to explore a slightly different approach to reducing
spinlock contention—by introducing a simple execution time threshold. If
a query’s execution time exceeds this threshold, it is recorded in
pg_stat_statements; otherwise, it is ignored. As Alexander [0] pointed
There should be a really good reason IMO to do something other than the
existing pattern of using custom_query_jumble.
I scanned through the thread and could not find a discussion on this,
but maybe others have an opinion.
> > This case with an array passed to aa function seems to cause a regr
on that uses this format.
>From e193fa6b99102c805e048d2cb70476291cd82fc3 Mon Sep 17 00:00:00 2001
From: Dmitrii Dolgov <9erthali...@gmail.com>
Date: Tue, 3 Dec 2024 14:55:45 +0100
Subject: [PATCH v25] Prevent jumbling of every element in ArrayExpr
pg_stat_statements produces multiple
On Fri, Feb 14, 2025 at 10:36:48AM +0100, Álvaro Herrera wrote:
> On 2025-Feb-14, Julien Rouhaud wrote:
>
> > Since the merging is a yes/no option (I think there used to be some
> > discussions
> > about having a threshold or some other fancy modes), maybe you could instead
> > differentiate the
On 2025-Feb-14, Julien Rouhaud wrote:
> Since the merging is a yes/no option (I think there used to be some
> discussions
> about having a threshold or some other fancy modes), maybe you could instead
> differentiate the merged version by have 2 constants rather than this "..." or
> something lik
Hi,
On Fri, Feb 14, 2025 at 09:36:08AM +0100, Dmitry Dolgov wrote:
> > On Thu, Feb 13, 2025 at 05:08:45PM GMT, Sami Imseih wrote:
> > This case with an array passed to aa function seems to cause a regression
> > in pg_stat_statements query text. As you can see the text is in
he implementation
simple to give the patch a chance. So far I'm inclined to leave Param
for the future work, although of course I'm open to discussion.
> This case with an array passed to aa function seems to cause a regression
> in pg_stat_statements query text. As you can see the
postgres-# ;
--
(0 rows)
postgres=# select query, queryid, calls from pg_stat_statements where
query like 'select%from foo where%' order by stats_since asc;
query |
queryid
ue-looking list scan:
I'm pretty sure there was some reason behind it, but when you pointed it
out that reason has promptly vanished in a puff of confusion. Fixed.
>From 212f5534fb0f99e5daa74ea4464231faec157a58 Mon Sep 17 00:00:00 2001
From: Dmitrii Dolgov <9erthali...@gmail.com>
Date:
On 2025-Feb-13, Dmitry Dolgov wrote:
> Here is how it looks like (posting only the first patch, since we
> concentrate on it). This version handles just a little more to cover
> simpe cases like the implicit convertion above. The GUC is also moved
> out from pgss and renamed to query_id_merge_valu
>
> > create table t (a float);
> > select i from t where i in (1, 2);
> > select i from t where i in (1, '2');
> > select i from t where i in ('1', 2);
> > select i from t where i in ('1', '2');
> > select i from t wher
ect i from t where i in (1, '2');
> select i from t where i in ('1', 2);
> select i from t where i in ('1', '2');
> select i from t where i in (1.0, 1.0);
Yep, the current version I've got so far produces the same
pg_stat_statements entry for al
ortant to handle this better than what the posted
> patch does, than improving the lexing in presence of other lexical
> elements in the query. With the current patch I get _five_
> pg_stat_statements entries from these queries above, where only one of
> them was able to apply merging o
int here is that the datatype differs for the constants from the
lexer down in each of these cases.)
I think it's more important to handle this better than what the posted
patch does, than improving the lexing in presence of other lexical
elements in the query. With the
> On Tue, Feb 11, 2025 at 08:00:27PM GMT, Dmitry Dolgov wrote:
> > Hmm, what about doing something much simpler, such as testing whether
> > there's just a CoerceViaIO/RelabelType around a Const or a one-parameter
> > function call of an immutable boostrap-OID function that has a Const as
> > argum
> On Tue, Feb 11, 2025 at 07:51:43PM GMT, Álvaro Herrera wrote:
> On 2025-Feb-11, Dmitry Dolgov wrote:
>
> > > On Tue, Feb 11, 2025 at 10:49:59AM GMT, Sami Imseih wrote:
> > > I have only looked at 0001, but I am wondering why
> > > query_id_const_merge is a
On 2025-Feb-11, Sami Imseih wrote:
> I have only looked at 0001, but I am wondering why
> query_id_const_merge is a pg_stat_statements GUC
> rather than a core GUC?
I was wondering the same thing and found the explanation
here:
https://postgr.es/m/ztmuctymis3n3...@paquier.xyz
On 2025-Feb-11, Dmitry Dolgov wrote:
> > On Tue, Feb 11, 2025 at 10:49:59AM GMT, Sami Imseih wrote:
> > I have only looked at 0001, but I am wondering why
> > query_id_const_merge is a pg_stat_statements GUC
> > rather than a core GUC?
>
> It was move
> On Tue, Feb 11, 2025 at 10:49:59AM GMT, Sami Imseih wrote:
> I have only looked at 0001, but I am wondering why
> query_id_const_merge is a pg_stat_statements GUC
> rather than a core GUC?
It was moved from being a core GUC into a pg_stat_statements GUC on the request
from t
On 2025-Feb-11, Sami Imseih wrote:
> I do not have an explanation from the patch yet, but I have a test
> that appears to show unexpected results. I only tested a few datatypes,
> but from what I observe, some merge as expected and others do not;
> i.e. int columns merge correctly but bigint do no
col_float in (1, 2, 3);
select from foo where col_float in (1, 2, 3, 4);
select query, queryid, calls from pg_stat_statements where query like
'select from foo where%' order by 1 desc ;
"""
postgres=# show pg_stat_statements.query_id_const_merge ;
I have only looked at 0001, but I am wondering why
query_id_const_merge is a pg_stat_statements GUC
rather than a core GUC?
The dependency of pg_stat_statements to take advantage
of this useful feature does not seem right.
For example if the user does not have pg_stat_statements enabled,
but are
Hello
I noticed something that surprised me at first, but on further looking
it should have been obvious: setting pg_stat_statements.query_id_const_merge
affects the query ID for all readers of it, not just pg_stat_statement.
This is good because it preserves the property that pg_stat_activity
ent
Hi hackers,
Since current patch is in the commitfest with the status 'Ready for
committer', I’d like to summarize what it does, the problems it
addresses, and answer the key questions raised in the discussion thread.
Enabling pg_stat_statements can cause a performance drop due t
pg_stat_statements which will likely occur
on larger machines.
I also did not see this thread [1] mentioned in the thread above,
but one of the reasons pg_stat_statements.track_planning
was turned off by default was due to the additional spinlock
acquire to track the planning stats. Bringing this up as
> To summarize the results of all benchmarks, I compiled them into a table:
Thanks for compiling the benchmark data above.
The main benefit of this patch will be to give the user
a toggle if they are observing high spinlock contention
due to pg_stat_statements which will likely occur
on lar
On 29.01.2025 21:52, Ilia Evdokimov wrote:
... I also attached the benchmark.sh
script used to generate the output.
In my opinion, if we can't observe bottleneck of spinlock on 32 CPUs,
we should determine the CPU count at which it becomes. This will help
us understand the scale of the p
> and we've been trying to solve a non-existent problem?
Anecdotally speaking, Most users will encounter bottlenecks
due to exclusive locks on pgss hash ( dealloc and garbage collection )
more often than they will on the spinlock. The spinlock will likely
become more of an issue when you are not s
1 - 100 of 1209 matches
Mail list logo
