On 20.02.22 01:39, Tom Lane wrote:
Hm, wouldn't it be less code to just use printf?
Meh --- it'd be different from the way we do it in the rest
of initdb, and it would not be "less code". Maybe it'd run
a shade faster, but I refuse to believe that that'd be
enough to matter.
There is a
Hi,
On 2022-02-19 20:46:26 -0500, Tom Lane wrote:
> I tried it like that (full patch attached) and the results are intensely
> disappointing. On my Mac laptop, the time needed for 50 iterations of
> initdb drops from 16.8 sec to 16.75 sec.
Hm. I'd hoped for at least a little bit bigger win. But
I wrote:
> However, redirection does sound like a very easy answer ...
I tried it like that (full patch attached) and the results are
intensely disappointing. On my Mac laptop, the time needed for
50 iterations of initdb drops from 16.8 sec to 16.75 sec.
On my RHEL8 workstation, the change is
Hi,
On February 19, 2022 4:39:38 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> A quick way to prototype the moving the handlign to the backend would be to
>> just call postgres with input redirection from postgres.bki...
>
>Hmm. I was thinking of inventing an include-file command in the
Andres Freund writes:
> A quick way to prototype the moving the handlign to the backend would be to
> just call postgres with input redirection from postgres.bki...
Hmm. I was thinking of inventing an include-file command in the
BKI language, and making initdb just send an INCLUDE command.
Hi,
On 2022-02-19 18:35:18 -0500, Tom Lane wrote:
> Here's an initial patch that gets rid of the need for initdb to
> change the contents of postgres.bki before feeding it to the
> bootstrap backend. After this, we could look at having the
> backend read the file directly.
Cool!
> I don't
Here's an initial patch that gets rid of the need for initdb to
change the contents of postgres.bki before feeding it to the
bootstrap backend. After this, we could look at having the
backend read the file directly.
I don't really detect any speed change from getting rid of initdb's
string
On 2/17/22 10:36, Robert Haas wrote:
> On Wed, Feb 16, 2022 at 2:50 PM Andres Freund wrote:
>>> initdb is already plenty fast enough for any plausible production
>>> usage; it's cases like check-world where we wish it were faster.
>> It's not just our own usage though. I've seen it be a
On Wed, Feb 16, 2022 at 2:50 PM Andres Freund wrote:
> > initdb is already plenty fast enough for any plausible production
> > usage; it's cases like check-world where we wish it were faster.
>
> It's not just our own usage though. I've seen it be a noticable time in test
> suites of applications
Andres Freund writes:
> On 2022-02-16 13:24:41 -0500, Tom Lane wrote:
>> I remembered the reason why it's done that way: if we replaced those
>> values during genbki.pl, the contents of postgres.bki would become
>> architecture-dependent, belying its distribution as a "share" file.
> Hm.
Hi,
On 2022-02-16 13:24:41 -0500, Tom Lane wrote:
> I remembered the reason why it's done that way: if we replaced those
> values during genbki.pl, the contents of postgres.bki would become
> architecture-dependent, belying its distribution as a "share" file.
> While we don't absolutely have to
Andres Freund writes:
> Sure, there's a few tokens that we replace in initdb. As it turns out there's
> only two rows that are actually variable. The username of the initial
> superuser in pg_authid and the pg_database row for template 1, where encoding,
> lc_collate and lc_ctype varies. The rest
Hi,
On 2022-02-16 11:47:31 +0100, Peter Eisentraut wrote:
> On 16.02.22 03:12, Andres Freund wrote:
> > Sure, there's a few tokens that we replace in initdb. As it turns out
> > there's
> > only two rows that are actually variable. The username of the initial
> > superuser in pg_authid and the
On 16.02.22 03:12, Andres Freund wrote:
Sure, there's a few tokens that we replace in initdb. As it turns out there's
only two rows that are actually variable. The username of the initial
superuser in pg_authid and the pg_database row for template 1, where encoding,
lc_collate and lc_ctype
On Wed, Feb 16, 2022 at 9:12 AM Andres Freund wrote:
> To me the division of labor between initdb and bootstrap doesn't make much
> sense anymore:
[...]
> I don't plan to work on this immediately, but I thought it's worth bringing up
> anyway.
Added TODO item "Rationalize division of labor
Hi,
[1] reminded me of a topic that I wanted to bring up at some point:
To me the division of labor between initdb and bootstrap doesn't make much
sense anymore:
initdb reads postgres.bki, replaces a few tokens, starts postgres in bootstrap
mode, and then painstakenly feeds bootstrap.bki lines
16 matches
Mail list logo
