On 5/3/2025 03:27, Alexander Korotkov wrote:
On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov <lepi...@gmail.com> wrote:
2. As usage of root->tuple_fraction RelOptInfo it has been criticized,
do you think we could limit this to some simple cases? For instance,
check that RelOptInfo is the final result relation for given root.
I believe that using tuple_fraction is not an issue. Instead, it serves
as a flag that allows the upper-level optimisation to consider
additional options. The upper-level optimiser has more variants to
examine and will select the optimal path based on the knowledge
available at that level. Therefore, we're not introducing a mistake
here; we're simply adding extra work in the narrow case. However, having
only the bottom-up planning process, I don't see how we could avoid this
additional workload.
Yes, but if we can assume root->tuple_fraction applies to result of
Append, it's strange we apply the same tuple fraction to all the child
rels. Latter rels should less likely be used at all and perhaps
should have less tuple_fraction.
Of course, it may happen. But I'm not sure it is a common rule.
Using LIMIT, we usually select data according to specific clauses.
Imagine, we need TOP-100 ranked goods. Appending partitions of goods, we
will use the index on the 'rating' column. But who knows how top-rated
goods are spread across partitions? Maybe a single partition contains
all of them? So, we need to select 100 top-rated goods from each partition.
Hence, applying the same limit to each partition seems reasonable, right?
--
regards, Andrei Lepikhov
