sion. Thank you for your time and consideration. Best regards,Ilia Evdokimov,Tantor Labs LLC.
extension into PostgreSQL.
Kind regards,
Ilia Evdokimov,
Tantor Labs LLC.
From 6316706c42996219e507bb6ded9dd1e872180e38 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Tue, 6 Feb 2024 18:11:04 +0300
Subject: [PATCH] pg_stat_advisor extension
---
contrib/Makefile
u can see the message of suggestion
creating statistics with name 't_i_j' on 'i', 'j' columns from 't' table.
Thank you for your understanding, patience, and continued support.
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
ng forward to your thoughts and feedback.
Regards,
Ilia Evdokimov,
Tantor Labs LLC.
From f87f4a57e532d57f43dab4764d08ddf83d9f3d8f Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Thu, 8 Feb 2024 16:00:57 +0300
Subject: [PATCH] 'pg_stat_advisor' extension.
This serves as a hook into t
will make it inconvenient for everyone to read the messages. I apologize for the inconvenience caused. Regards, Ilia Evdokimov, TantorLabs LLC.
write them
in this thread.
Regards,
Ilia Evdokimov,
Tantor Labs LLC.
ked `list_free(colnames)` afterwards.
If anyone is aware of where the list is being freed or has any
suggestions for improvement, I would greatly appreciate your input.
Best Regards,
Ilia Evdokimov,
TantorLabs LCC
From cd7aa7ac5904501085a980944dc3c18f42721c06 Mon Sep 17 00:00:00 2001
From: I
in()` is the last function to use this list, it
would be more efficient to free the `List` at the point of its declaration.
I'll attach new patch where I free the lists.
Regards,
Ilia Evdokimov,
Tantor Labs LCC
From 853c5bc854bcc03e791cf32cc8cad7b257ec558f Mon Sep 17 00:00:00 2001
From: I
ill call `list_free` immediately after
`addRangeTableEntryForJoin()`. The new patch is attached.
Thanks for reviewing. I'm looking forward to new suggestions.
Regards,
Ilia Evdokimov,
Tantor Labs LCC
From b545770d57ac3ca137e9ad97c004576e77213648 Mon Sep 17 00:00:00 2001
From: Ilia Evdo
experiences and any improvements you might suggest. Best regards, Ilia
Evdokimov Tantor Labs LLC.
From eb998bea96a3640d240afa63e08cc8cf98925bf7 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Mon, 13 May 2024 14:41:59 +0300
Subject: [PATCH] 'pg_stat_advisor' extension
This servic
e, its
placement, or if you'd like to see a different criterion used, I would
greatly appreciate your feedback.
Looking forward to your thoughts and suggestions.
--
Regards,
Ilia Evdokimov,
Tantor Labs LCC.
From 8e038f16d45d5f8c39c7204fc661ed4b7f504a63 Mon Sep 17 00:00:00 2001
From: Ilia Evdo
On 05.09.2024 23:32, Euler Taveira wrote:
On Thu, Sep 5, 2024, at 1:05 PM, Ilia Evdokimov wrote:
It's quite common that poor query performance can be attributed to
inaccurate row estimations by the planner. To make it easier to
detect these discrepancies, rather than scrutinizin
Hi everyone,
I've taken a closer look at the patch and realized that we don't need
the new function 'mcv_clause_selectivity_var_op_var()' we can use
'mcv_clause_selectivity()' instead.
I'm attaching the updated patch and test generator.
--
Regards,
Ilia
Hi, hackers
I'm sure this refactoring is useful because it's more readable when
datum value is binary or not.
However, I can see a little improvement. We can declare variable 'bytea
*outputbytes' in 'else' because variable is used nowhere except this plac
sent this mail twice, I'm sorry :)
Regards
Ilia Evdokimov,
Tantor Labs.
ed previous patch: 18
Estimated current patch: 9
Actual: 9
[1]:
https://www.postgresql.org/message-id/flat/9e0a12e0-c05f-b193-ed3d-fe88bc1e5fe1%40enterprisedb.com
I look forward to any feedback or suggestions from the community.
Best regars,
Ilia Evdokimov
Tantor Lab
urate
estimation.
[1]:
https://www.postgresql.org/message-id/7C0F91B5-8A43-428B-8D31-556458720305%40enterprisedb.com
Ilia Evdokimov,
Tantor Labs LLC.
the performance did not drop. In general, it'd
be better to do more tests and those listed by Tomas with new attached
patch.From fa67b0fa34408c0f1b0c9f079b84e7c71f3b5599 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Sat, 10 Aug 2024 14:35:25 +0300
Subject: [PATCH] Add support fo
ike in query
SELECT regexp_substr('abcdefghi', 'd.q') IS NULL AS t;
Regards
Ilia Evdokimov,
Tantor Labs LLC.
On 10.8.24 22:37, Andrei Zubkov wrote:
Hi, Ilia!
Do you consider not to create new table in pg_catalog but to save
statistics in existing table? I mean pg_class or
pg_stat_progress_analyze, pg_stat_progress_vacuum?
Thank you for your interest on our patch!
*_progress views is not our case.
And I have one suggestion for pg_stat_vacuum_database: I suppose we
should add database's name column after 'dboid' column because it is
difficult to read statistics without database's name. We could call it
'datname' just like in 'pg_stat_database' view.
On 15.8.24 11:49, Alena Rybakina wrote:
I have some suggestions:
1. pgstatfuncs.c in functions tuplestore_put_for_database() and
tuplestore_put_for_relation you can remove 'nulls' array if
you're sure that columns cannot be NULL.
We need to use this for tuplestore_putvalues function.
ng, please let me know. I’m also open to any
other suggestions.
--
Regards,
Ilia Evdokimov,
Tantor Labs LCC.
From fab0575ef1350cb700b6fc079230397ecb5ca19d Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Mon, 19 Aug 2024 12:08:53 +0300
Subject: [PATCH] Remove redundant NULL check for cla
On 19.8.24 18:02, Tom Lane wrote:
Ilia Evdokimov writes:
In the `clause_selectivity_ext()` function, there’s a comment regarding
a NULL clause check that asks, "can this still happen?". I decided to
investigate whether this scenario is still valid.
Here’s what I found after rev
as not sent to hackers because of big size of attached
file. Now I sent only test.
[1]:
https://www.postgresql.org/message-id/ecc0b08a-518d-7ad6-17ed-a5e962fc4f5f%40enterprisedb.com
[2]:
https://www.postgresql.org/message-id/flat/c8c0ff31-3a8a-7562-bbd3-78b2ec65f16c%40enterprisedb.com
Are you certain that all tables are included in `pg_stat_vacuum_tables`?
I'm asking because of the following:
SELECT count(*) FROM pg_stat_all_tables ;
count
---
108
(1 row)
SELECT count(*) FROM pg_stat_vacuum_tables ;
count
---
20
(1 row)
--
Regards,
Ilia Evdokimov,
T
oment, adjusting the
|autovacuum_analyze_threshold| and |autovacuum_analyze_scale_factor|
parameters might be the solution.
--
Regards,
Ilia Evdokimov,
Tantor Labs LCC.
llo,
Are you sure we can refactor loop by 'smgrclose()'? I see it is not
quite the same.
Regards,
Ilia Evdokimov,
Tantor Labs LLC.
abase_S_ for consistency with pg_stat_vacuum_tables
and pg_stat_vacuum_indexes
--
Regards,
Ilia Evdokimov,
Tantor Labs LLC.
lestore.
Hi Alexander,
The 'tuplestorestate' variable may be initialized at line 64 if it is
NULL. You should consider initializing this variable earlier.
Regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 08.11.2024 22:23, Alena Rybakina wrote:
Hi! Thank you for review!
On 07.11.2024 17:49, Ilia Evdokimov wrote:
Thank you for fixing it.
1) I have found some typos in the test output files (out-files) when
running 'make check' and 'make check-world'. These typo
s_read | .
---++-+--+-----
public | t | 21416 | 4425 | ..
(1 row)
Regards,
Ilia Evdokimov,
Tantor Labs LLC.
feedback regarding the comments in the code, the naming of variables or
documentation. I’m always open to discussion.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From edba1bcefa85e995ec3e9df6c9e8d30adcd940b9 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Tue, 26 Nov 2024
flexibility by allowing critical queries to be captured while
maintaining efficient sampling.
I attached new version of patch.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From c33e1ae07e8eb4f797b47e7deb07e6322b1375a3 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Tue, 19 Nov 2024
statistics in pg_stat_statements.
This patch serves as a proof of concept (POC), and I would like to hear
your thoughts on whether such an approach is viable and applicable.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.From b19081bd257014f0c4046570097e4bc7b28a3126 Mon Sep 17 00:00:00 2001
From: Ilia
On 19.11.2024 15:11, Andrey M. Borodin wrote:
On 18 Nov 2024, at 23:33, Ilia Evdokimov wrote:
Hi hackers,
Under high-load scenarios with a significant number of transactions per second,
pg_stat_statements introduces substantial overhead due to the collection and
storage of statistics
input in the psql command-line interface.
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
t
turns out that pgss is the cause, the only painless solution without
restarting the instance is sampling. The current pgss's parameters are
not optimal for achieving this.
BTW, I forgot to include a case of nested statements. Either all will be
tracked or none. I attached new version of
Hi everyone,
I found typo in comment auto_explain.c line 282 (/* Enable per-node
instrumentation iff log_analyze is required. */).
Not 'iff' but 'if'.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 27.11.2024 15:54, Heikki Linnakangas wrote:
On 27/11/2024 14:46, Ilia Evdokimov wrote:
Hi everyone,
I found typo in comment auto_explain.c line 282 (/* Enable per-node
instrumentation iff log_analyze is required. */).
Not 'iff' but 'if'.
It's short for &qu
In my opinion, the patches are semantically correct. However, not all
dead code has been removed - I'm referring to pgstat_update_snapshot().
Also, the tests need to be fixed.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On 26.11.2024 01:15, Ilia Evdokimov wrote:
On 22.11.2024 09:08, Alexander Korotkov wrote:
On Wed, Nov 20, 2024 at 12:07 AM Michael Paquier wrote:
On Tue, Nov 19, 2024 at 09:39:21AM -0500, Greg Sabino Mullane wrote:
Oh, and a +1 in general to the patch, OP, although it would also be nice
g all 'RestrictInfos' during deparsing using
'expression_tree_mutator()' is not optimal. However, I don't see an
alternative. Perhaps it could be done this earlier in extended_stats.c
to avoid the need for cleanup later ...
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
significance. To address this, I propose introducing a macro
STATS_MIN_ROWS to represent this value and consolidating its explanation
in a single place, making the code more consistent and readable.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From d3cbea3875fdc9866c86c64c0d0e0d838887040c Mon
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,
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.
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 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
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
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
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.
the feature.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
rther.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
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
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
/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,
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.
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.
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.
support this patch.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
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
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
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
So do I. Firstly, I'll think how to explain it.
--
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
be improved, or other ideas worth exploring?
--
Best regards.
Ilia Evdokimov,
Tantor Labs LLC.
From 68f5451019b261bf03a222f5a05ac57cd0fb9a24 Mon Sep 17 00:00:00 2001
From: Ilia Evdokimov
Date: Thu, 21 Nov 2024 11:24:03 +0300
Subject: [PATCH] Allow setting sample ratio for pg_stat_statements
New
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 understand,
especially for new contributors
ry execution
behavior without introducing unnecessary complexity or false precision.
I would appreciate any thoughts or feedback on this proposal.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index a201ed3082..b3f7fa87
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
=
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,
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.
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
-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
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
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
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]
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
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
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 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
.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
_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
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
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.
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
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
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.
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
e,
benchmarking Memoize is definitely necessary. Thanks for the information!
--
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
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.
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.
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
1 - 100 of 151 matches
Mail list logo
