public inbox for [email protected]  

help / color / mirror / Atom feed

From: David Rowley <[email protected]>
To: Lauro Ojeda <[email protected]>
Cc: [email protected]
Subject: Re: Partition pruning is not happening (even in PG18)
Date: Tue, 30 Sep 2025 09:08:16 +1300
Message-ID: <CAApHDvrB5WcbU_DqyGtejDyepqpdFNGJhdea+8xuxwNwQ50kFQ@mail.gmail.com> (raw)
In-Reply-To: <CAG3nGZ-PpRarYRqbMzLZoVkma+ifSmNjmuPSL0tT3_opMZ1Dxg@mail.gmail.com>
References: <CAG3nGZ-Pi=ExcSiRpCmjJWpqT+Ugd4p+xHC-K7M33kvAh4xZNQ@mail.gmail.com>
	<CAApHDvrydoBmh5MJQUMpvqaxNOioB2U-jTGahQevYjT_YFfDCw@mail.gmail.com>
	<CAG3nGZ-PpRarYRqbMzLZoVkma+ifSmNjmuPSL0tT3_opMZ1Dxg@mail.gmail.com>

On Tue, 30 Sept 2025 at 02:49, Lauro Ojeda <[email protected]> wrote:
> By looking into it, I have the impression there is a bug in the costing sum in that situation, where the cost of the "never executed" partitions should be deducted from the final cost estimation, which would make pruning to be the preferred option in this case.
>
> Are my assumptions correct?

The "never executed" part is not determined at planning time. It's
only something the executor gets to figure out, and by that time, it's
no good adjusting the plan's costs since the planner has already
decided on what it thinks the best plan is and it's too late to change
that.

> Is there anything I could do to influence the planner to dismiss the cost of "never executed" scans?

Not in the general sense, but for nodes that are "never executed" due
to run-time partition pruning. It would be possible to make some
assumptions during planning. The planner would need to do some extra
work during planning to figure out if an AppendPath or MergeAppend
path has run-time prunable parameters.  If those parameters plus any
non-parameterized quals result in pruning being possible at run-time,
then *maybe* there's something we can do better. For equi joins, you
could assume that only 1 of the Append children will be scanned.  The
planner will have no idea which one, but it could do something like
total_append_cost / number_of_append_children. For other join types,
it's much less clear how that would work. There have been previous
proposals to do something with DEFAULT_INEQ_SEL or maybe
DEFAULT_RANGE_INEQ_SEL. I've forgotten the exact details as it was
about 8 years ago.

David

view thread (7+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Partition pruning is not happening (even in PG18)
  In-Reply-To: <CAApHDvrB5WcbU_DqyGtejDyepqpdFNGJhdea+8xuxwNwQ50kFQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox