ries" field. I'm
unsure why MemoizePath.calls becomes Memoize.lookups. Seems
unnecessary and just means more brain space being used to maintain a
mental model.
Agree.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
I've prepared the updated patches as discussed, including the addition
of estimated lookups in the EXPLAIN output for Memoize. Please let me
know if you have any feedback or further suggestions.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 021cc6f5629a607cab3a0ec1021fc5f102dc043
. These tests
currently don't have any masking in place, so the new output fields may
cause instability across platforms.
Wrapping the line in costs or verbose would help with test stability,
but doing that only to simplify test output doesn't look like the right
reason. Maybe it mak
ke it easier to evaluate
the usefulness of each part.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 99a23dfae4415a3eb88c3847deefae3c2103077d Mon Sep 17 00:00:00 2001
From: Evdokimov Ilia
Date: Tue, 15 Apr 2025 00:47:26 +0300
Subject: [PATCH v7 1/2] Show ndistinct and est_entries in EXPLAI
registered the patch in the upcoming CommitFest 2025-07 to ensure
it stays in the review process.
https://commitfest.postgresql.org/patch/5697/
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
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.
On 31.03.2025 23:59, Ilia Evdokimov wrote:
We definitely shouldn’t remove the row counts < 1 check, since there
are many places in the planner where we divide by rows. This mechanism
was added specifically to prevent division by zero. Also, allowing
rows estimates below 1 can sometimes m
n EXPLAIN,
I’m happy to proceed. Otherwise, perhaps this is something better suited
for extension.
[0]:
https://www.postgresql.org/message-id/CA%2BTgmoZ8qXiZmmn4P9Mk1cf2mjMMLFPOjSasCjuKSiHFcm-ncw%40mail.gmail.com
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
only instance I found.
I’m attaching a patch with the fix. If anyone spots a similar case
elsewhere, please let me know.
[0]:
https://www.postgresql.org/message-id/CAApHDvpq2gOt3gnzkd4Ud%3DwrT7YRGrF3zb29jgWzDsYEhETrOA%40mail.gmail.com
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From
ng planner expectations at that point
can be the most useful. I attached v6 patch with changes.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 36ed866e3d28a709fd1133a89ecdc7a2654a657f Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Wed, 2 Apr 2025 10:49:27 +0300
Subject: [PATCH v
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
d by multiple significant values from the
MCV list, rather than just the single most frequent one. This should
lead to a more accurate selectivity estimate, better reflecting the
actual data distribution.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 02.04.2025 19:39, Alena Rybakina wrote:
I see that I need to add a walker that, when traversing the tree,
determines whether there are conditions under which pull-up is
impossible - the presence of
volatility of functions and other restrictions, and leave the
transformation for the var o
On 28.03.2025 15:20, Ilia Evdokimov wrote:
Then we need to decide clearly what exactly to display in EXPLAIN for
the Memoize node: absolute values (estimated distinct keys and
estimated cache capacity) or ratios (hit_ratio and evict_ratio).
Ratios have the advantage of quickly reflecting the
cheaper-looking plans that may not perform well in
practice. For example, choosing a Nested Loop instead of a more
appropriate Hash Join.
Allowing fractional rows > 1 might help improve planner accuracy in some
cases, but this needs further study to fully understand the impact.
--
Best rega
hts?
--
Best Regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 79af33e499730a4bd0553832b23bf68c90817c6e Mon Sep 17 00:00:00 2001
From: Evdokimov Ilia
Date: Fri, 28 Mar 2025 15:17:09 +0300
Subject: [PATCH v5] Show ndistinct and est_entries in EXPLAIN for Memoize
---
src/backend/commands/explain.c
such as
rhs_vardata, clearly indicating its role related specifically to the
right side of the join condition.
I attached v2 patch with changes.
Any thoughts?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 6ec99d712d7fda3cc18a8700318158f54bae4c55 Mon Sep 17 00:00:00 2001
From: Evdokimov
stimated or how many entries the
planner thought would fit in memory. This makes it very difficult to
understand whether Memoize was a good choice or not, or how to fix it
when it performs poorly.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
necessary details to compute these values.
For now, I’m attaching a rebased v4 patch, which includes the fix for
ExplainPropertyText.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From b60e508583b1cb7f30814cef6f39c4b570693350 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Fri, 21 Mar
this thread I'll fix in the next
patches if it will be necessary.
So far, I have tested it on small machines. There are no performance
issues yet. I'll run benchmarks on larger ones soon.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 02a9b4793deb74f2e67dacabec259c4cd929d9
e,
benchmarking Memoize is definitely necessary. Thanks for the information!
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
led, it should not cause any performance regression in
normal execution. However, reviewers should be especially careful when
verifying test outputs, as this change could affect plan details in
regression tests.
Any thoughts?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 2e7d9bd9bfe5
lly
for collecting statistics exclusively from parent tables. Therefore,
autocompletion makes sense primarily for the ANALYZE case.
Any thoughts?
--
Best regaards,
Ilia Evdokimov,
Tantor Labs LLC.
te after typing the first letter.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 19.03.2025 08:12, vignesh C wrote:
How about we handle it like in the attached patch?
Apart from this, similar handling was required for "ANALYZE VERBOSE" also.
Regards,
Vignesh
It would be nice if this works with VACUUM VERBOSE ANALYZE ONLY table;
--
Best regards,
Ilia
anid = 0;
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
oach for computing queryid [0]. It seems reasonable to apply the
same logic to the planid calculation as well.
[0]:
https://www.postgresql.org/message-id/flat/Z9mkqplmUpQ4xG52%40msg.df7cb.de#efb20f01bec32aeafd58e5d4ab0dfc16
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 18.03.2025 17:57, Ilia Evdokimov wrote:
Hi,
Thank you for the patch. However, Is it ok if I can't tab 'ONLY' in
VACUUM ANALYZE command?
CREATE TABLE only_parted (a int, b text) PARTITION BY LIST (a);
CREATE TABLE only_parted1 PARTITION OF only_parted FOR VALUES IN (
s=1000.00 loops=1)
Buffers: shared read=5
Planning:
Buffers: shared hit=31 read=16
Planning Time: 0.751 ms
Execution Time: 12.599 ms
(18 rows)
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
WARNING: VACUUM ONLY of partitioned table "only_parted" has no effect
VACUUM
postgres=#
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 18.03.2025 14:46, Ilia Evdokimov wrote:
However, I have a question: what value should planid have when we
execute the standard planner without using a planner_hook? For
example, if pg_stat_statementsis disabled, would planid default to
zero? If zero is the expected default, should we
the essence of the
test.
What do you think?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
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,
After commit eaf5027 we should add information about wal_buffers_full.
Any thoughts?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 03.03.2025 18:57, Ilia Evdokimov wrote:
hi hackers,
When estimating the selectivity of an OR clause without extended
statistics, we assume that the conditions are independent. However, it
is quite common to see queries like (a = 1 OR a = 2). In such cases,
the assumption of independence
:
-if (cplan && cplan->status == PLAN_CACHE_STATUS_CUSTOM_PLAN)
+if (cplan->status == PLAN_CACHE_STATUS_CUSTOM_PLAN)
2. Should we add Assert(kind == PGSS_EXEC) at this place to ensure that
generic_plan_calls and custom_plan_calls are only incremented when
appropriate?
--
Best
On 27.02.2025 17:40, Aleksander Alekseev wrote:
Hi,
This function is currently not covered by any tests. The proposed
patch fixes this.
--
Best regards,
Aleksander Alekseev
Hi,
+1. The 'POSISTION' tests include 'text', 'bits' types, but not 'bytea
pen to any suggestions, feedback, or improvements.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 0a1f465b1be1c413a2db6c4f6be1a50db8fb105f Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Mon, 3 Mar 2025 18:30:30 +0300
Subject: [PATCH v1] Improve selectivity estimation for OR clauseswit
. Also, given
that everyone is likely busy with the higher-priority task of IN
normalization in pg_stat_statements, I will leave the rebased v19-patch
here and move it back to Ready for Committer, as the patch has already
been it.
Any suggestions are welcome.
--
Best regards,
Ilia Evdokimov
ologies for the oversight! I've attached a fix for this on last commit
7717f63.
[0]:
https://www.postgresql.org/message-id/40663fc5-edac-4b45-a2aa-a76976700ed9%40tantorlabs.com
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.s
On 27.02.2025 19:51, Robert Haas wrote:
On Mon, Feb 24, 2025 at 2:16 PM Robert Haas wrote:
On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov
wrote:
If no one is concerned about rows being a non-integer, then I support
this, as it's quite strange for the average rows to be an integer onl
hooks, IMO.
--
Sami
Got it. I think it's worth considering, but not within the scope of this
thread.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 18.02.2025 01:13, Ilia Evdokimov wrote:
Thank you for reviewing! I agree with all of them. I updated patch v9
with these changes.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
Hi hackers,
I’ve addressed all your comments on the v9 patch for updating the
descriptions of
attached patch with changes in
documentation.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 7ce5d477ddd360ca3a5045949cc0e44db0658887 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Mon, 24 Feb 2025 20:07:09 +0300
Subject: [PATCH v1] EXPLAIN: Always use
prepared for potential issues. But
how to determine this boundary in postgres, I am not sure. I am
confident that you will have a much better sense and experience of how
to handle it.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
7 00:00:00 2001
From: Ilia Evdokimov
Date: Mon, 24 Feb 2025 13:55:15 +0300
Subject: [PATCH v12] Update documentation after changing the rows format in
EXPLAIN ANALYZE
Following commit ddb17e3, the format of the average rows" field
in EXPLAIN ANALYZE was modified to always display fractional v
added back at any time if needed. I attached patch with fixes.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 1bf58c5725ab9a906f57117a2c2e1ee7f287f5d5 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Fri, 21 Feb 2025 12:38:13 +0300
Subject: [PATCH v1] Remove unused vardata parameters in
ery has not been normalized. Is it a bug, expected
or undefined behavior?
[0]:
https://www.postgresql.org/message-id/CAA5RZ0vxn_UiUkUK5SdngObLZzw40RhafB7SHydxzBw2_xjjiA%40mail.gmail.com
-- Best regards, Ilia Evdokimov, Tantor Labs LLC.
From b8f88dcd4d44a11301776455cc133bb3e859d000 Mon Sep 17 00:00:00 200
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 18.02.2025 23:55, Andrei Lepikhov wrote:
On 17/2/2025 15:19, Robert Haas wrote:
On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov
if (nloops > 1)
Instead of:
if (nloops > 1 && rows_is_fractonal)
I don't think it's really safe to just cast a double back to int64. In
here.
Thank you for reviewing! I agree with all of them. I updated patch v9
with these changes.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 44f60949a4636eb649d29d752a55a8410213d12e Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Tue, 18 Feb 2025 01:02:15 +0300
Subject: [PATCH v9] S
On 17.02.2025 17:19, Robert Haas wrote:
On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov
wrote:
You're right—floor shouldn't be used since it behaves differently across
platforms, as Tom also pointed out earlier. I like the idea of using %,
but since the compiler doesn't allow
n and log_parameter_max_length do not follow the
conventions we have adopted. I mean we should use numerals instead of
words. I'm attaching a patch to fix this.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 71274740583fcac642b6e74adabeeaf3992f2e1a Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
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 15.02.2025 11:46, Andrei Lepikhov wrote:
On 13/2/2025 21:42, Robert Haas wrote:
On Thu, Feb 13, 2025 at 4:05 AM Ilia Evdokimov
wrote:
1. Documentation
(v9-0001-Clarify-display-of-rows-as-decimal-fractions-DOC.patch)
One thing that bothers me is that the documentation explains how to
postgresql.org/message-id/CAPpHfdsTKAQqC3A48-MGQhrhfEamXZPb64w%3Dutk7thQcOMNr7Q%40mail.gmail.com
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From aaf82d481aeb40458dfd7debfb3bcd254f33cdee Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Fri, 14 Feb 2025 15:40:36 +0300
Subject: [PATCH v16] All
unchanged since we agreed on a fixed format of
two decimal places.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 789d98383988ef6d3b0bc2c6b9b5c73a83ffd6d4 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Thu, 13 Feb 2025 11:19:03 +0300
Subject: [PATCH v9] Clarify display of rows as deci
So do I. Firstly, I'll think how to explain it.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
zeros after the decimal point. We do not want to clutter the rows
with unnecessary zeros.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From e1a46d3fa5a4d20b6ea4728b2a3955f375539295 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Tue, 11 Feb 2025 22:12:41 +0300
Subject: [PATCH] Clarify dis
ve wal_buffers_full next to wal_records, wal_fpi and wal_bytes?
This way, all WAL-related information would be grouped together.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 11.02.2025 03:09, Jonathan S. Katz wrote:
Hi,
Attached is a draft of the 2025-02-13 update release announcement.
Please provide feedback no later than 2025-02-13 0:00 UTC.
Thanks,
Jonathan
you may simply shutdown PostgreSQL
you may simply shut down PostgreSQL
--
Best regards,
Ilia
small values"; the 'rows' in decimal will only
happen with small values? What would be a "small value" in this context? My main
point here is more that I think that it would be good to mention *why* the
'rows' can be decimal, not just describe that it could be decimal.
As for 'small values', it means that the average rows is between zero
and one, to avoid rounding errors and misunderstanding. I think this
would be ideal.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
her list, we
define newWhere and apply both cases.
When I run 'make -C contrib/ check', tests of postgres_fdw extension
failed. I might be wrong, but you should be careful with LIMIT.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
diff -U3 /home/ilia/postgres/contrib/postgres
ot;If a subplan node ..."
* Maybe wrap 'rows' with ?
I agree with the last two points. As for the first one—maybe we could
simply state that the average rows value can be decimal, especially for
very small values?
[0]:
https://www.postgresql.org/message-id/a9393107-6bb9-c835-50b7-c0f453a514b8%40postgrespro.ru
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
s approach? I'm happy to discuss further.
[0]: https://commitfest.postgresql.org/51/2837/
[1]: https://www.postgresql.org/message-id/Zz0MFPq1s4WFxxpL%40paquier.xyz
[2]: https://commitfest.postgresql.org/29/2634/
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From c9540fac9f6d6ad6d15acdaad
On 08.02.2025 00:01, Matheus Alcantara wrote:
Em sex., 7 de fev. de 2025 às 17:41, Ilia Evdokimov
escreveu:
Strange, I don't have any problems to apply it on master.
postgres$ git branch
* master
postgres$ git pull
Already up to date.
postgres$ git apply
v6-0001-Clarify-di
/partition_prune.out: patch does not apply
Hi
Strange, I don't have any problems to apply it on master.
postgres$ git branch
* master
postgres$ git pull
Already up to date.
postgres$ git apply
v6-0001-Clarify-display-of-rows-and-loops-as-decimal-fraction.patch
postgres$
--
Best regards,
rs and developers.
Any feedback, suggestions, or additions to the tests are welcome and
appreciated.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From e2b2e591e0df5a7e2ed589182b204781229d5754 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Fri, 7 Feb 2025 00:29:53 +0300
Subject: [PATCH v1] Add
the given conditions, and that any issues with this
can be detected in the right place, then I agree. The patch likely makes
worse.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
rther.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
support this patch.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
dependency statistics are
applied, Analyzing dependencies stats often takes the longest compared
to other statistics, and if users could see the extended statistics for
dependencies upfront, they might be able to remove them if they're not
useful for the plan.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
the feature.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
ation in the code
accurately reflects the behavior of pg_regress.
Attached is a small patch correcting this.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From d2ef1b2ff2f42bc38eb2d2d87201a2822d53d8b5 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Sun, 2 Feb 2025 21:35:10 +0300
Subjec
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 o
On 28.01.2025 23:50, Ilia Evdokimov wrote:
If anyone has the capability to run this benchmark on machines with
more
CPUs or with different queries, it would be nice. I’d appreciate any
suggestions or feedback.
I wanted to share some additional benchmarks I ran as well
on a r8g.48xlarge
not only to
the Makefile but also to meson.build. I've included that in the v14 patch.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 7c9d45325e29a65259740d5255d39f9f57ee6fba Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Tue, 28 Jan 2025 23:04:34 +0300
Subject: [PATCH]
27;Ready for Committer,' I believe it is now better for
upstream inclusion, with improved details in tests and documentation. Do
you have any further suggestions?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 149688fe3bccce25f8d01dfe8c01444555dce03c Mon Sep 17 00:00:00
-01 Commitfest:
https://commitfest.postgresql.org/51/5390/
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From ddbc6af2af511ff342b183cb13a9027edadc0ad3 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Thu, 23 Jan 2025 11:31:57 +0300
Subject: [PATCH v1] Allow setting sample ratio for
On 20.01.2025 17:20, Ilia Evdokimov wrote:
On 15.01.2025 20:16, Sami Imseih wrote:
Probably, but first I suggest benchmarking with sampling applied to
all queries. If the results are good, we can later filter certain
queries based on different characteristics.
Absolutely. The benchmark
re
CPUs or with different queries, it would be nice. I’d appreciate any
suggestions or feedback.
--.
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
pg_stat_statements.sample_rate = 1.0
cpu = 85%
pgbench -c 45 -j 45 -T 200 -f pgbench_script.sql --progress=10 pgbench
pgbench (16.6)
starti
_state) <= log_xact_sample_rate);
Sorry for the delayed reply. Andrey was right about this
suggestion—first, it makes the code more readable for others, and
second, it avoids engaging the PRNG on edge values of 0.0 and 1.0. I’ve
attached patch v11 with these
4a038%40tantorlabs.com
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From e8d9911bd7b1384112773977c1a30a476fc77471 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Tue, 14 Jan 2025 12:18:52 +0300
Subject: [PATCH v1] Allow setting sample ratio for pg_stat_statements
New c
On 11.01.2025 14:10, Ilia Evdokimov wrote:
On 11.01.2025 12:15, Guillaume Lelarge wrote:
Thanks for your patch, this looks like a very interesting feature
that I'd like to see in a future release.
It did a quick run: patch OK, make OK, make install OK, but make
check fails quite
On 11.01.2025 17:02, Guillaume Lelarge wrote:
Le sam. 11 janv. 2025 à 12:10, Ilia Evdokimov
a écrit :
On 11.01.2025 12:15, Guillaume Lelarge wrote:
Thanks for your patch, this looks like a very interesting feature
that I'd like to see in a future release.
It did a
; values are displayed so they appear as decimal
fractions with two digits after the decimal point.
I attached fixed patch.
Any suggestions?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From a934fbd278350edf7a3a3e7fe620a0027ceb2580 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Sat, 1
this threshold would not be sampled.
Certainly I'll fix all Andrey's comments.
What are your thoughts on this approach?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
=
pg_prng_double(&pg_global_prng_state) < pgss_sample_rate;
else
current_query_sampled = false;
}
I think you should put this in a function like
update_current_query_sampled. I've attached a diff file with the changes.
Agree, thanks.
--
Best regards,
Ilia Evdokimov,
ave a benchmark that proves
that a user can benefit with sampling in those types of
workloads.
Ah, so patch version 9 might be the best fit to achieve this. I’ll need
to benchmark it on a large, high-concurrency machine then.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 08.01.2025 22:39, Ilia Evdokimov wrote:
After the changes in v9-patch, won’t all the necessary queries now be
normalized? Since there are no longer any restrictions in the parser
hook, queries will be normalized as usual, and pgss_planner,
pgss_ExecutorStart, and ExecutorEnd will simply
lways open to feedback.
I attached v9 patch with changes and test above.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From b40ab06155cac38e57f0551a3858d0574d96865f Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Wed, 8 Jan 2025 22:15:02 +0300
Subject: [PATCH] Allow setting sample ratio f
ank you for pointing this out. Your solution looks interesting,
but I'd like to explore other ways to solve the issue besides making it
available to all hooks. If I don't find anything better, I'll go with yours.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
I completely forgot about ordering pg_stat_statements in the test, which
is why the test failed in [0]. I've added ORDER BY query COLLATE "C" to
avoid any non-deterministic ordering in the table.
[0]: https://cirrus-ci.com/task/5724458477944832
--
Best regards,
Ilia Evdokimov,
On 06.01.2025 18:57, Andrey M. Borodin wrote:
On 6 Jan 2025, at 15:50, Ilia Evdokimov wrote:
Any suggestions for improvements?
The patch looks good to me, just a few nits.
0. Perhaps, we could have a test for edge values of 0 and 1. I do not insist,
just an idea to think about.
I would
On 03.01.2025 18:42, Fabrízio de Royes Mello wrote:
On Fri, Jan 3, 2025 at 11:09 AM Ilia Evdokimov
wrote:
Hi hackers,
I've attached a small patch that remove unused parameter 'rel' from
the static function lookup_var_attr_stats() in extended_stats.c
Whil
On 10.12.2024 17:35, Ilia Evdokimov wrote:
Hi everyone,
I attached previous sampling patch for pg_stat_statements (v4).
Suggestions like sampling based on execution time remain unfeasible,
as pg_stat_statements can track query during query planning, not
execution.
To evaluate the
.org/message-id/flat/CADkLM%3DcB0rF3p_FuWRTMSV0983ihTRpsH%2BOCpNyiqE7Wk0vUWA%40mail.gmail.com
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From a59af002463c962f153c79202b5f091a24fa6199 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Fri, 3 Jan 2025 16:46:51 +0300
Subject: [PATCH] Remove
On 10.12.2024 16:32, Ilia Evdokimov wrote:
On 09.12.2024 16:10, Ilia Evdokimov wrote:
Hi hackers,
The repeated use of the number 300 in the ANALYZE-related code
creates redundancy and relies on scattered, sometimes unclear,
comments to explain its purpose. This can make the code harder to
l hit=4
-> Seq Scan on tc (actual rows=1 loops=1)
Filter: (aid = 1)
Buffers: local hit=1
(14 rows)
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
hat I can see, total rows is never used
in the current implementation, so this patch removes it
If there are reasons to keep this parameter, or if there's anything I
might have missed, I'd be happy to discuss further.
--
Best regards,
Ilia Evdokimov,
Tantor
1 - 100 of 147 matches
Mail list logo
