Re: Propose a new hook for mutating the query bounds

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Xiaozhe Yao <askxzyao(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Propose a new hook for mutating the query bounds
Date: 2021-11-17 14:49:58
Message-ID: 2414428.1637160598@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Xiaozhe Yao <askxzyao(at)gmail(dot)com> writes:

+ if (mutate_bounds_hook) {
+ mutate_bounds_hook(root, &constval, isgt, iseq);
+ }

It seems unlikely that this could do anything actually useful,
and impossible that it could do anything useful without enormous waste
of cycles along the way. Basically, each time one calls scalarineqsel,
the hook would have to re-analyze the entire query to see if it should do
anything. Most of the time the answer would be "no", after a lot of
cycles wasted. It would also have to keep some state (where?) to
coordinate mutation of different Consts in a WHERE clause. And why only
a hook in scalarineqsel? Is that really the only context that you'd need
to adjust the results in?

Another important deficiency in this API spec is that the hook has no
idea *which* constant it's being called on, so I don't see how it could
really deliver correct answers at all.

I can buy that ML techniques might provide a way to improve selectivity
estimates overall, but I think inserting them would be better done with
a much higher-level hook, maybe about at the level of
clauselist_selectivity.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-11-17 15:07:17 Re: pg_upgrade test for binary compatibility of core data types
Previous Message Thomas 2021-11-17 14:45:26 Re: Patch: Range Merge Join