Re: Reduce "Var IS [NOT] NULL" quals during constant folding
От | Richard Guo |
---|---|
Тема | Re: Reduce "Var IS [NOT] NULL" quals during constant folding |
Дата | |
Msg-id | CAMbWs497DeTDspMzuu69g85uZtG3u8QJME+AWRcwrcUgS3m19Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reduce "Var IS [NOT] NULL" quals during constant folding (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Reduce "Var IS [NOT] NULL" quals during constant folding
|
Список | pgsql-hackers |
On Wed, Aug 20, 2025 at 2:38 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > On Wed, Jul 30, 2025 at 03:17:38PM +0900, Richard Guo wrote: > > I didn't observe measurable impact, but perhaps others can run more > > representative tests and demonstrate otherwise. > > > > (I recall Peter E. mentioned he might run some tests to measure the > > impact. Not sure if he's had the time to do that yet.) > There is still an open item for this one, but it's not clear whether we are > planning to do anything about this for v18, especially since nobody has > shown measurable performance impact. Does anyone want to argue for > addressing this for v18, or shall we close the open item as "Won't Fix"? I don't think we're likely to do anything about this for v18. Actually, I still doubt that the extra table_open call brings any measurable performance impact, especially since the lock is already held and the relation is likely already present in the relcache. Also, I still don't think moving the expansion of virtual generated columns to the rewriter (as Tom proposed) is a better idea. It turned out to have several problems that need to be fixed with the help of PHVs, which is why we moved the expansion into the planner. Thanks Richard
В списке pgsql-hackers по дате отправления: