On Tue, Apr 9, 2024 at 12:03 AM Michael Paquier wrote:
> Hmm, is that productive? This patch has been waiting on author since
> the 1st of February, and it was already moved from the CF 2024-01 to
> 2024-03. It would make more sense to me to mark it as RwF, then
> resubmit if there is still
On Mon, Apr 08, 2024 at 11:11:07AM +0300, Andrey M. Borodin wrote:
> This is kind reminder that this thread is waiting for your response.
> CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Hmm, is that productive? This patch has been waiting on author since
the 1st of February,
> On 22 Sep 2023, at 18:50, Matthias van de Meent
> wrote:
Hi Matthias!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey Borodin.
[0]
On Wed, 8 Nov 2023 at 12:50, Peter Eisentraut wrote:
>
> On 08.11.23 08:16, Peter Eisentraut wrote:
> > On 19.09.23 20:05, Heikki Linnakangas wrote:
> >> One thing caught my eye though: We currently have an "open" command
> >> after every "create". Except for bootstrap relations; creating a
> >>
On 08.11.23 08:16, Peter Eisentraut wrote:
On 19.09.23 20:05, Heikki Linnakangas wrote:
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
On 19.09.23 20:05, Heikki Linnakangas wrote:
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
On Fri, 22 Sept 2023 at 00:25, Andres Freund wrote:
>
> Hi,
>
> On 2023-09-19 21:05:41 +0300, Heikki Linnakangas wrote:
> > 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
On Tue, 19 Sept 2023 at 20:05, Heikki Linnakangas wrote:
>
> 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
Hi,
On 2023-09-19 21:05:41 +0300, Heikki Linnakangas wrote:
> 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
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
On Tue, 12 Sept 2023 at 17:51, Matthias van de Meent
wrote:
>
> On Fri, 1 Sept 2023 at 19:52, Tom Lane wrote:
> >
> > Alvaro Herrera writes:
> > > On 2023-Sep-01, Matthias van de Meent wrote:
> > >> A potential addition to the patch would to stop manually closing
> > >> relations: initdb and
On Fri, 1 Sept 2023 at 19:52, Tom Lane wrote:
>
> Alvaro Herrera 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'
Alvaro Herrera 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
On Fri, 1 Sept 2023 at 19:43, Alvaro Herrera wrote:
>
> 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
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
Hi,
Whilst looking at PostgreSQL's bootstrapping process, I noticed that
postgres.bki contains quite a few occurrances of the pattern "open
$catname; close $catname".
I suppose this pattern isn't too expensive, but according to my
limited research a combined open+close cycle doens't do anything
16 matches
Mail list logo
