| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why does bootstrap and later initdb stages happen via client? |
| Date: | 2021-09-09 12:11:50 |
| Message-ID: | c52c0ea8-6cf6-1679-006d-329d9dbf97a3@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08.09.21 21:07, Andres Freund wrote:
> There of course is historical raisins for things happening in initdb - the
> setup logic didn't use to be C. But now that it is C, it seems a bit absurd to
> read bootstrap data in initdb, write the data to a pipe, and then read it
> again in the backend. It for sure doesn't make things faster.
A couple of things I was looking into a while ago: We could probably
get a bit of performance by replacing the line-by-line substitutions
(replace_token()) by processing the whole buffer at once. And we could
get even more performance by not doing any post-processing of the files
at all. For example, we don't need to replace_token() SIZEOF_POINTER,
which is known at compile time. Handling ENCODING, LC_COLLATE, etc. is
not quite as obvious, but moving some of that logic into the backend
could be helpful in that direction.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2021-09-09 12:30:29 | Re: drop tablespace failed when location contains .. on win32 |
| Previous Message | Christoph Berg | 2021-09-09 11:52:41 | trap instead of error on 32 TiB table |