On 3/7/2025 02:30, Richard Guo wrote:
On Wed, Jul 2, 2025 at 6:44 PM Andrei Lepikhov <lepi...@gmail.com> 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
negatively impact planner performance. As I mentioned before, I have
only envisioned rare instances where join eliminations may reduce the
number of relations and clause evaluations resulting in a constant.
I wonder how you arrived at the conclusion that these cases are rare.
If they truly are, then why have we invested so much effort in
optimizing for them?
There is no direct connection between effort and frequency; it primarily
depends on personal desire. As you might find, much of the effort goes
into convincing the community.
These specific cases should be rare from the Postgres perspective, the
planner's code remains simple based on the assumption that crafting the
appropriate query is the user's responsibility.
I also wonder why you think we should collect all catalog information
at the very early stage of the planner, given that most of it is only
used much later -- after RelOptInfos have been created. If the goal
is to avoid redundant catalog retrieval for the same relation in
get_relation_info(), perhaps adding a caching mechanism within that
function would be a more targeted solution. I don't see a strong
reason for moving get_relation_info() to the very beginning of the
planner.
This indicates that there is still room for further exploration and
discussion. For starters, the 'Redundant NullTest' issue is not the only
concern. Additionally, Postgres processes pull-up transformation blindly
without considering the cost model. However, each pull-up has its corner
case, and in practice, we often see new complaints arise after a new
pull-up technique is committed. One possible solution I envision could
be to examine indexes and/or make raw initial estimations to avoid
problematic pull-up cases.
--
regards, Andrei Lepikhov
