On Tue, Dec 7, 2021 at 5:55 PM Robert Haas wrote:
> On Sat, Dec 4, 2021 at 7:44 PM Michael Paquier wrote:
> > My main worry here is that this changes slightly the definition of
> > doPageWrites across stable branches at the end of recovery as there
> > could be records generated there. Note that
On Sat, Dec 4, 2021 at 7:44 PM Michael Paquier wrote:
> My main worry here is that this changes slightly the definition of
> doPageWrites across stable branches at the end of recovery as there
> could be records generated there. Note that GetFullPageWriteInfo()
> gets called in XLogInsert(), whil
On Tue, Nov 16, 2021 at 09:41:58AM -0500, Robert Haas wrote:
> Maybe I'm not understanding you properly here, but it seems like you
> might be forgetting that this is a local variable and thus every
> backend is going to have something different. In the startup process,
> it will be initialized by
There are a couple typos. "uninitalized," in one place.
Also,
+* If this is either a bootstrap process nor a standalone backend, start
Is "either .. nor" correct? It looks very wrong to me. I think you
meant "either .. or".
Overall, this patch seems mostly about documenting some unde
On Sat, Nov 20, 2021 at 3:22 PM Heikki Linnakangas wrote:
> But here's yet another idea: We could initialize RedoRecPtr and
> doPageWrites in InitXLogInsert(). It would seem like a pretty natural
> place for it.
I considered that, but it seemed like an abstraction violation to me,
because that co
On 17/11/2021 00:04, Andres Freund wrote:
On 2021-11-16 16:30:27 -0500, Robert Haas wrote:
I'm still not entirely clear on whether you prefer v1-0002, v2-0002,
or something else.
I think it basically doesn't matter much. It's such a small piece of the cost
compared to either the cost of a sing
On 2021-11-16 16:30:27 -0500, Robert Haas wrote:
> I'm still not entirely clear on whether you prefer v1-0002, v2-0002,
> or something else.
I think it basically doesn't matter much. It's such a small piece of the cost
compared to either the cost of a single insert or the ratio between
RedoRecPtr/
On Tue, Nov 16, 2021 at 3:42 PM Andres Freund wrote:
> On 2021-11-16 15:19:19 -0500, Robert Haas wrote:
> > > Hm. I think this might included a bunch of convoluting factors that make
> > > it
> > > hard to judge the actual size of the performance difference.
> >
> > Yes, I think so, too.
>
> FWIW
Hi,
On 2021-11-16 15:19:19 -0500, Robert Haas wrote:
> > Hm. I think this might included a bunch of convoluting factors that make it
> > hard to judge the actual size of the performance difference.
>
> Yes, I think so, too.
FWIW I ran that pgench thing I presented upthread, and I didn't see any
On Tue, Nov 16, 2021 at 2:27 PM Andres Freund wrote:
> Is this with assertions enabled? Because on my workstation (which likely is
> slower on a single-core basis than your laptop) I get around half of this with
> an optimized build (and a non-optimized build rarely is worth using as a
> measuring
Hi,
On 2021-11-15 16:29:28 -0500, Robert Haas wrote:
> v1: 0.378 ms
> v2: 0.391 ms
> common base commit (10eae82b2): 0.376 ms
Is this with assertions enabled? Because on my workstation (which likely is
slower on a single-core basis than your laptop) I get around half of this with
an optimized bui
Hi,
On 2021-11-11 12:15:03 -0500, Robert Haas wrote:
> The reason why RecoveryInProgress() has critical side effects is that
> it calls InitXLOGAccess(). It turns out that the only critical thing
> that InitXLOGAccess() does is call InitXLogInsert().[1] If a backend
> doesn't call InitXLogInsert()
On Mon, Nov 15, 2021 at 9:34 PM Michael Paquier wrote:
> Patch 0001 means that the startup process would set up the structures
> to be able to build WAL records before running any kind of recovery
> action rather than doing it when it really needs it. That's fine by
> me.
Great, thanks. I think
On Mon, Nov 15, 2021 at 10:09:17PM +, Bossart, Nathan wrote:
> On 11/15/21, 1:30 PM, "Robert Haas" wrote:
>> Here's a new version that does it that way. Any other opinions?
>
> LGTM
Patch 0001 means that the startup process would set up the structures
to be able to build WAL records before r
On 11/15/21, 1:30 PM, "Robert Haas" wrote:
> Here's a new version that does it that way. Any other opinions?
LGTM
> The best thing I could come up with for a test case for this was to
> try repeatedly making a new connection and running "SELECT
> txid_current()", which will cause just one WAL re
On Fri, Nov 12, 2021 at 10:23 AM Bossart, Nathan wrote:
> 0001 looks reasonable to me.
Cool.
> Unless there's a demonstrable performance benefit from adding the
> branch, my preference is to leave it out. I could be off-base, but it
> seems possible that future changes might end up depending on
On 11/11/21, 9:20 AM, "Robert Haas" wrote:
> memory, and not much is lost if they are set up and not used. So, in
> 0001, I propose to move the call to InitXLogInsert() from
> InitXLOGAccess() to BaseInit(). That means every backend will do it
> the first time it starts up. It also means that Crea
17 matches
Mail list logo
