seems beneficial
for practice. When the internal structure is a bushy join tree,
producing even a single tuple can be costly. SQL Server's Spool node
addresses this issue, and people sometimes experience confusion
detecting degradation during migration with specific queries.
--
regards, Andrei Lepikhov
like in the following example:
EXPLAIN (COSTS OFF)
SELECT * FROM parted WHERE a > 2 AND b > 10;
/*
Result
One-Time Filter: false
*/
--
regards, Andrei Lepikhov
this extension without a
rush until it is stable - I think at least the case of parallel
execution may be enhanced.
[1]
https://www.postgresql.org/message-id/CAG0ozMrtK_u8Uf5KNZUmRNuMphV5tnC5DEhRBNRGK%2BK4L506xw%40mail.gmail.com
--
regards, Andrei Lepikhov
On 3/31/25 12:18, Richard Guo wrote:
On Mon, Mar 31, 2025 at 6:46 PM Andrei Lepikhov wrote:
Nested Loop
-> Seq Scan on t t2
-> Nested Loop
-> Seq Scan on t t1
-> Subquery Scan on t3
Filter: ((t2.a = t3.a) AND
updated
to reflect the changes?
It makes sense: for now, it seems that PHV removal should be used in the
case of an outer join removal. In the case of SJE, logically we make a
replacement, not a removal, and we should not reduce the number of
entities involved.
--
regards, Andrei Lepikhov
On 4/1/25 09:18, Richard Guo wrote:
On Mon, Mar 31, 2025 at 7:33 PM Andrei Lepikhov wrote:
and I don't get the case. As I see, ANTI/SEMI join just transforms to
the regular join and it is still not the case. May you be more specific?
Upthread, you said that a qual contained in ppi_cl
strate principles and test the code on a single planner node. It
only deserves src/test/modules because it is not helpful for a broad
audience.
--
regards, Andrei Lepikhov
ueryId or planId may be resolved.
--
regards, Andrei Lepikhov
. So, here, we will add a new parameter and avoid touching the
core code.
But I would give +1 to current approach if it were done in a shorter time.
--
regards, Andrei Lepikhov
Hi,
Playing with the feature, I found a slightly irritating permutation -
even if this code doesn't group any clauses, it may permute positions of
the quals. See:
DROP TABLE IF EXISTS main_tbl;
CREATE TABLE main_tbl(id bigint, hundred int, thousand int);
CREATE INDEX mt_hundred_ix ON main_tbl
E id = ANY (some_business_logic($1));
EXPLAIN (ANALYZE, COSTS OFF) EXECUTE test(1);
Also in that case we wouldn't need to decompose a ScalarArrayOpExpr to
the list of OpExpr clauses to prune partitions.
--
regards, Andrei Lepikhov
/evictions show that.
--
regards, Andrei Lepikhov
OIN, but if
the subquery refers to LHS, it just not be transformed to the SEMI/ANTI
join.
Anyway, if you provide an example or just a sketch, I will be happy to
discover it.
--
regards, Andrei Lepikhov
On 7/5/2025 08:57, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-07 08:02:
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_ext() we explicitly check for path
being
On 7/5/2025 11:12, Álvaro Herrera wrote:
On 2025-May-07, Andrei Lepikhov wrote:
If it's not new in pg18, then adding a commitfest entry in the "bug
fixes" category is the right thing. I'd suggest to CC the committer and
author of the patch that caused the bug; with the
Hi,
Because there was no answer to the issue [1], I'll add it to the next
commitfest. Feel free to reject it if my logic on choosing the merge
append path is wrong.
[1]
https://www.postgresql.org/message-id/3ca271fa-ca5c-458c-8934-eb148622b...@gmail.com
--
regards, Andrei Lepikhov
On 5/5/2025 15:56, Alexander Pyhalov wrote:
Andrei Lepikhov писал(а) 2025-05-05 14:38:
Also logic a bit differs if path is NULL. In
get_cheapest_path_for_pathkeys_ext() we explicitly check for path being
NULL, in get_cheapest_fractional_path_for_pathkeys_ext() only after
calculating sort cost
On 9/12/24 16:57, Tomas Vondra wrote:
On 9/12/24 12:12, David Rowley wrote:
On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov wrote:
Initial problem causes wrong cost_sort estimation. Right now I think
about providing cost_sort() the sort clauses instead of (or in addition
to) the pathkeys
concluded that moving to the core is
too much and discussed the idea of letting another module filter
queries/columns/length of the query string to store in
pg_stat_statements through hooks - 'extend the extension'.
--
regards, Andrei Lepikhov
do not have a universal
solution worth proposing upstream. Do you have any public implementation
of the array_sample_reservoir to play with?
--
regards, Andrei Lepikhov
implement the logic
of random sampling.
Implementation of that in the core will need a new "skip result" node
and new syntax, which may be too much if a workaround is found.
--
regards, Andrei Lepikhov
king about :D
A custom SRF seems great to me. You may propose such an aggregate in the
core - it seems it doesn't even need any syntax changes. For example:
SELECT * FROM (SELECT sample(q, 10, ) FROM (SELECT ...) AS q);
or something like that.
--
regards, Andrei Lepikhov
ge-id/flat/25d6a2cd161673d51373b7e07e6d9dd6%40postgrespro.ru
[2]
https://www.postgresql.org/message-id/f0206ef2-6b5a-4d07-8770-cfa7cd30f...@gmail.com
--
regards, Andrei Lepikhov
On 22/5/2025 16:17, Robert Haas wrote:
On Sat, May 3, 2025 at 2:44 PM Andrei Lepikhov wrote:
I have one additional proposal.
I currently use this interface and have noticed that the parameter
`option_name` in the RegisterExtensionExplainOption routine is
case-sensitive. Since SQL treats our
aster: in my test bench, it takes 1250ms on
average versus 1430ms, and it also has lower costs - the same for data
with and without massive numbers of duplicates. Playing with sizes of
inputs, I see the same behaviour.
--
regards, Andrei Lepikhov
merge_sort.sql
Description: application/sql
From 37
l is also beyond the pg_hint_plan control ...
--
regards, Andrei Lepikhov
ate 'never
existed' relations and removed ones. In that sense, up to v.15, Postgres
saved RelOptInfo after removing the join (see e9a20e4).
--
regards, Andrei Lepikhov
On 3/6/2025 15:38, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote:
To establish a stable foundation for discussion, I conducted simple
tests - see, for example, a couple of queries in the attachment. As I
see it, Sort->Append works faster: in my test bench,
On 3/6/2025 16:05, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
Additionally, as I mentioned earlier, the primary reason for choosing
MergeAppend in the regression test was a slight total cost difference
that triggered the startup cost comparison.
May you
On 4/6/2025 00:41, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov wrote:
On 3/6/2025 16:05, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
Additionally, as I mentioned earlier, the primary reason for choosing
MergeAppend in the
l
solutions and reduce development impulse in the area.
--
regards, Andrei Lepikhov
and manipulating
generic/custom plan switching logic.
--
regards, Andrei Lepikhov
w test coverage.
--
regards,
Andrei Lepikhov
Postgres ProfessionalFrom 1b2a42da985fbd0287472ba3b348528d8931ba9d Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Date: Thu, 26 Jun 2025 15:11:03 +0200
Subject: [PATCH 1/3] Basic infrastructure to link, unlink, and free pathnodes.
add_path
nd extensions can be more assured that they will
receive the requested plan type.
If there are no objections, I will add this patch to the next commitfest.
--
regards, Andrei Lepikhov
From 7dd2140fdbdd842f454ac631ca15ec80a2ea1cab Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Da
On 19/5/2025 15:21, Robert Haas wrote:
On Thu, May 15, 2025 at 9:03 AM Andrei Lepikhov wrote:
2. IncrementalSort is not always more effective - it depends on the
column's number of groups. In my experience, a non-cost-based decision
one day meets the problematic case, and the people who
https://www.postgresql.org/message-id/a74d2648-c93e-4686-a8d4-2843515b8...@gmail.com
--
regards, Andrei Lepikhov
On 27/6/2025 12:01, Andrei Lepikhov wrote:
On 6/2/2024 13:51, Ashutosh Bapat wrote:
On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
wrote:
First patch is no longer required. Here's rebased set
The patches are raw. make check has some crashes that I need to fix. I
am waiting to hear wh
d why it should work.
[1]
https://open.substack.com/pub/danolivo/p/on-expressions-reordering-in-postgres
--
regards, Andrei Lepikhov
On 14/7/2025 06:52, Amit Langote wrote:
On Fri, Jul 11, 2025 at 11:09 PM Andrei Lepikhov wrote:
To support that efficiently, the slot can store a new tts_min_valid
field to indicate the lowest attno that needs deforming.
Alternatively, we could use a per-attribute flag array (with
TupleDesc
On 3/7/2025 04:02, Tender Wang wrote:
Andrei Lepikhov mailto:lepi...@gmail.com>> 于2025年7
月2日周三 22:29写道：
On 30/6/2025 04:38, Tender Wang wrote:
> Do you think it's worth doing this?
>
>
> Hi all,
>
> I have added this patch
On 3/7/2025 02:30, Richard Guo wrote:
On Wed, Jul 2, 2025 at 6:44 PM Andrei Lepikhov wrote:
I apologise for the confusion in my previous message. I am not
suggesting that we postpone this. Instead, I would like an explanation
of why you believe that accessing the table statistics earlier could
) the
data needed for get_relation_info. In cases where multiple subqueries
reference the same table, it could save some cycles and memory.
--
regards, Andrei Lepikhov
)i;
with a backspace or an 'AS' keyword?
--
regards, Andrei Lepikhov
On 2/7/2025 11:14, Richard Guo wrote:
On Wed, Jul 2, 2025 at 4:32 PM Andrei Lepikhov wrote:
I must say that I appreciate Tom's idea and see significant benefits in
making the parse tree a read-only structure. In complex queries, it can
be frustrating to make copies of the parse tree, le
On 2/7/2025 03:24, Richard Guo wrote:
On Tue, Jul 1, 2025 at 10:57 PM Andrei Lepikhov wrote:
I like the general idea of this work. But I wonder, why is a new hash
table designed to store only the notnullattnums field? From the
discussion, it is not apparent why not to cache all (or most of
c interface and introduced a plan
type identification logic, why do it twice?
--
regards, Andrei Lepikhov
of referencing the entire
list of planned statements during the execution of a single statement.
The is_last_plan_generic field may be sufficient at first glance.
--
regards, Andrei Lepikhov
t for the record. This patch obviously resolves my issue [1] too ...
[1]
https://www.postgresql.org/message-id/39ac724e-58c8-4661-9e88-cb4ee97cb...@gmail.com
--
regards, Andrei Lepikhov
seems that a callback-based or subscription-based model could be
worth exploring.
--
regards, Andrei Lepikhov
e reused later, and it may be
profitable for an analytics-related extension to spend extra cycles and
apply optimisation tricks more boldly.
--
regards, Andrei Lepikhov
provide some insights into the planner's decision.
Will you add the ExplainOpenGroup call to the final version of the patch?
--
regards, Andrei Lepikhov
On 24/7/2025 17:05, Tom Lane wrote:
> Andrei Lepikhov writes:
>> I see you have chosen a variant with a new enum instead of a pointer to
>> a plan cache entry. I wonder if you could write the arguments
>> supporting this choice?
>
> Pointing to a plan cache entry wou
:PlanCacheSource reference.
--
regards, Andrei Lepikhov
this is a missed opportunity, as even
an extension-based feedback system could pave the way for developments
in self-tuning DBMS. Plan cache entries seem to be the most suitable target
for this purpose, as they usually refer to a long-lived statement and already
contain some valuable data.
--
regards, Andrei Lepikhov
On 23/7/2025 02:11, David Rowley wrote:
> On Wed, 23 Jul 2025 at 02:35, Andrei Lepikhov wrote:
>> However, at first, I'd consider how it could be added to the
>> IncrementalSort and HashJoin. The number of estimated groups/buckets may
>> also provide some insights i
On 4/6/2025 00:41, Alexander Korotkov wrote:
On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov wrote:
For me, it seems like a continuation of the 7d8ac98 discussion. We may
charge a small fee for MergeAppend to adjust the balance, of course.
However, I think this small change requires a series of
On 18/7/2025 13:48, Ashutosh Bapat wrote:
On Mon, Jul 7, 2025 at 8:43 PM Andrei Lepikhov wrote:
if (!IsA(new_path, IndexPath))
- pfree(new_path);
+ free_path(new_path, 0, false);
Why don't we free the subpaths if they aren't referenced anymore?
During testing, I discovered that we
imple boolean is not
sufficient.
Sure. But I modestly hope you would add a CachedPlanSource pointer
solely to the PlannedStmt and restructure it a little as we discussed
above. And no new structures are needed. Am I wrong?
--
regards, Andrei Lepikhov
On 28/7/2025 08:46, Michael Paquier wrote:
On Mon, Jul 28, 2025 at 08:41:29AM +0200, Andrei Lepikhov wrote:
It looks good, but doesn't it seem too narrow?
For the use case of the thread which is to count the number of custom
vs generic plans, it would be good enough.
Sure, no objec
hedPlan hook may be introduced.
--
regards, Andrei Lepikhov
er
decisions.
I'm not sure it provides any answers - just existing techniques to ponder.
--
regards, Andrei Lepikhov
outer provides
even one more tuple, we immediately switch to the more conservative
version of the plan at runtime.
[1]
https://www.pgevents.ca/events/pgconfdev2025/schedule/session/346-switching-between-query-plans-in-real-time-switch-join/
--
regards, Andrei Lepikhov
On 27/7/2025 00:51, Alexander Korotkov wrote:
On Tue, Jul 22, 2025 at 2:13 PM Andrei Lepikhov I've another idea. cost_tuplesort() puts 2.0 under logarithm to prefer
tuplesort over heapsort. I think we can adjust cost_gather_merge() and
cost_merge_append() to do the same. 0001
ed'. As I see, here is a bit different
classification used, not so obvious, at least for me.
--
regards, Andrei Lepikhov
iple
purposes.
Anyway, the extensibility model has never been an easy part of the
system to design. So, let's think about that as a first draft approach.
--
regards, Andrei Lepikhov
And any other plan also will be generic or custom, doesn't
it? It is interesting information about the plan source, of course, but
for the sake of performance analysis, it would be profitable to
understand the type of plan. However, the last sentence may be a subject
for another thread.
--
regards, Andrei Lepikhov
ies for plans prepared by the extended protocol, but
this may be possible in the future.
So, I meant that the source of the plan is one important characteristic,
and the type (custom or generic) is another, independent characteristic
--
regards, Andrei Lepikhov
hose being removed.
I believe it would be beneficial to address this issue now to prevent
potential problems in the future. See the patch attached.
--
regards, Andrei Lepikhov
From 5bf860bf703add87601286423e889fbab71cbc81 Mon Sep 17 00:00:00 2001
From: "Andrei V. Lepikhov"
Date: We
as they could be
reused for more tests than the ones we'd look at here.
I considered the worker_spi.c module, which demonstrates various SPI
usage patterns. It might be more beneficial to use this instead of
creating another test module, isn't it?
--
regards, Andrei Lepikhov
arely use the pg_extension_config_dump feature.
Additionally, the term 'secondary extension' is not entirely clear to me.
To ensure we are on the same page, it would be helpful to see the
specific case you are referring to as a regression test or TAP test
included with the patch.
--
401 - 470 of 470 matches
Mail list logo
