Startup subpaths in MergeAppend path - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Startup subpaths in MergeAppend path
Date
Msg-id f0206ef2-6b5a-4d07-8770-cfa7cd30f685@gmail.com
Whole thread Raw
List pgsql-hackers
Hi,

Upon reviewing [1], I noticed an inconsistency: within the 
add_paths_to_append_rel function, Postgres only constructs 
startup_subpaths when the rel->consider_startup flag is set to true. 
However, the generate_ordered_append_paths function generates these 
paths regardless of this flag.

After examining the code, I found no scenario where a startup-optimal 
path would be necessary if consider_startup is false. Impact on the 
planning time might be noticeable in partitioned cases. Therefore, does 
it make sense to include startup paths only when it is necessary?

I created a simple patch to address this issue, and it has successfully 
passed all regression tests. If I overlooked something, it would be 
beneficial to add a regression test demonstrating the necessity of 
startup paths regardless of declared limits.

Anyway, it will be beneficial to discuss this logic in the mailing list.

[1] 
https://www.postgresql.org/message-id/flat/25d6a2cd161673d51373b7e07e6d9dd6%40postgrespro.ru

-- 
regards, Andrei Lepikhov

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: m.korotkov@postgrespro.ru
Date:
Subject: Re: [PATCH] dynahash: add memory allocation failure check