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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: GenBKI emits useless open;close for catalogs without rows
Date: 2023-09-19 18:05:41
Message-ID: 286e368f-b884-8cfa-5c5a-22a743c6dd25@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18/09/2023 17:50, Matthias van de Meent wrote:
> (initdb takes about 73ms locally with syncing disabled)

That's impressive. It takes about 600 ms on my laptop. Of which about
140 ms goes into processing the BKI file. And that's with "initdb
-no-sync" option.

> Various methods of reducing the size of postgres.bki were applied, as
> detailed in the patch's commit message. I believe the current output
> is still quite human readable.

Overall this does not seem very worthwhile to me.

One thing caught my eye though: We currently have an "open" command
after every "create". Except for bootstrap relations; creating a
bootstrap relation opens it implicitly. That seems like a weird
inconsistency. If we make "create" to always open the relation, we can
both make it more consistent and save a few lines. That's maybe worth
doing, per the attached. It removes the "open" command altogether, as
it's not needed anymore.

Looking at "perf" profile of initdb, I also noticed that a small but
measurable amount of time is spent in the "isatty(0)" call in do_end().
Does anyone care about doing bootstrap mode interactively? We could
probably remove that.

--
Heikki Linnakangas
Neon (https://neon.tech)

Attachment Content-Type Size
remove-bootstrap-open.patch text/x-patch 5.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2023-09-19 18:20:06 Re: Disabling Heap-Only Tuples
Previous Message Tom Lane 2023-09-19 17:46:36 Re: Projection pushdown to index access method