Re: Reduce "Var IS [NOT] NULL" quals during constant folding
От | Nathan Bossart |
---|---|
Тема | Re: Reduce "Var IS [NOT] NULL" quals during constant folding |
Дата | |
Msg-id | aKS2qVOT0oE59MXd@nathan обсуждение исходный текст |
Ответ на | Re: Reduce "Var IS [NOT] NULL" quals during constant folding (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Reduce "Var IS [NOT] NULL" quals during constant folding
|
Список | pgsql-hackers |
On Wed, Jul 30, 2025 at 03:17:38PM +0900, Richard Guo wrote: > On Wed, Jul 30, 2025 at 3:45 AM Tomas Vondra <tomas@vondra.me> wrote: >> Does this mean we can close the PG18 open item tracking this? >> >> * virtual generated columns and planning speed >> Owner: Peter Eisentraut >> >> >> If I understand correctly, the commits went only to master, which means >> PG18 still does the table_open/table_close calls Tom complained about in >> [1] and [2]. > > You're right. This patchset is intended only for master, so it > doesn't address that open item for v18. > >> I think it'd be perfectly fine if it only affected cases with virtual >> generated columns, but AFAICS we do the open/close call for every >> relation. Has anyone tried to measure if the impact is measurable? I >> suspect it's negligible, we already hold a lock on the rel anyway >> (right?). But has anyone tried to measure if that's true? > > I ran a naive test on v18: selecting from 10 tables, comparing the > unmodified v18 with a hacked version where the call to > expand_virtual_generated_columns() was removed, 3 times each. Here > are the planning times I observed. > > [...] > > 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"? -- nathan
В списке pgsql-hackers по дате отправления: