Re: GenBKI emits useless open;close for catalogs without rows

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема Re: GenBKI emits useless open;close for catalogs without rows
Дата
Msg-id CAEze2Wi2Xgf9u+oLo3zgOZ-C=VsgpqQ-cXTNRKwSCXTG+y2Rqg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GenBKI emits useless open;close for catalogs without rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: GenBKI emits useless open;close for catalogs without rows  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers
On Fri, 1 Sept 2023 at 19:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > On 2023-Sep-01, Matthias van de Meent wrote:
> >> A potential addition to the patch would to stop manually closing
> >> relations: initdb and check-world succeed without manual 'close'
> >> operations because the 'open' command auto-closes the previous open
> >> relation (in boot_openrel). Testing also suggests that the last opened
> >> relation apparently doesn't need closing - check-world succeeds
> >> without issues (incl. with TAP enabled). That is therefore implemented
> >> in attached patch 2 - it removes the 'close' syntax in its entirety.
>
> > Hmm, what happens with the last relation in the bootstrap process?  Is
> > closerel() called via some other path for that one?
>
> Taking a quick census of existing closerel() callers: there is
> cleanup() in bootstrap.c, but it's called uncomfortably late
> and outside any transaction, so I misdoubt that it works
> properly if asked to actually shoulder any responsibility.
> (A little code reshuffling could fix that.)
> There are also a couple of low-level elog warnings in CREATE
> that would likely get triggered, though I suppose we could just
> remove those elogs.

Yes, that should be easy to fix.

> I guess my reaction to this patch is "why bother?".  It seems
> unlikely to yield any measurable benefit, though of course
> that guess could be wrong.

There is a small but measurable decrease in size of the generated bki
(2kb with both patches, on an initial 945kB), and there is some
related code that can be eliminated. If that's not worth bothering,
then I can drop the patch. Otherwise, I can update the patch to do the
cleanup that was within the transaction boundaries at the end of
boot_yyparse.

If decreasing the size of postgres.bki is not worth the effort, I'll
drop any effort on doing so, but considering that it is about 1MB of
our uncompressed distributables, I'd say decreases in size are worth
the effort, most of the time.

Kind regards,

Matthias van de Meent



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Detoasting optionally to make Explain-Analyze less misleading
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: sslinfo extension - add notbefore and notafter timestamps