From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_dump test instability
Date: Thu, 13 Sep 2018 09:56:02 -0400
Message-ID: <9881.1536846962@sss.pgh.pa.us> (raw)
In-Reply-To: <080c109e-0426-0aff-7a88-c0ea9399fa56@2ndquadrant.com>
References: <5137fe12-d0a2-4971-61b6-eb4e7e8875f8@2ndquadrant.com>
<32399.1535379095@sss.pgh.pa.us>
<20180827144138.GO3326@tamriel.snowman.net>
<1665.1535381158@sss.pgh.pa.us>
<20180827155943.GP3326@tamriel.snowman.net>
<1765.1535482037@sss.pgh.pa.us>
<406b7f39-039d-6cfc-6d36-ee797d214af7@2ndquadrant.com>
<6771.1536768395@sss.pgh.pa.us>
<080c109e-0426-0aff-7a88-c0ea9399fa56@2ndquadrant.com>
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 12/09/2018 18:06, Tom Lane wrote:
>> No. In both code paths, the array slot at index first_te is being
>> physically dropped from the set of valid entries (by incrementing
>> first_te). In the first path, that slot holds the item we want to
>> remove logically from the set, so that incrementing first_te is
>> all we have to do: the remaining entries are still in the range
>> first_te..last_te, and they're still sorted. In the second code
>> path, the item that was in that slot is still wanted as part of
>> the set, so we copy it into the valid range (overwriting the item
>> in slot i, which is no longer wanted). Now the valid range is
>> probably not sorted, so we have to flag that a re-sort is needed.
> I see. Why not shift all items up to the i'th up by one place, instead
> of moving only the first one? That way the sortedness would be
> preserved. Otherwise we'd move the first one into the middle, then
> sorting would move it to the front again, etc.
Hmmm ... might be worth doing, but I'm not sure. The steady-state cycle
will probably be that after one task has been dispatched, we'll sleep
until some task finishes and then that will unblock some pending items,
resulting in new entries at the end of the list, forcing a sort anyway
before we next dispatch a task. So I was expecting that avoiding a sort
here wasn't really going to be worth expending much effort for. But my
intuition about that could be wrong. I'll run a test case with some
instrumentation added and see how often we could avoid sorts by
memmove'ing.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@2ndquadrant.com, sfrost@snowman.net
Subject: Re: pg_dump test instability
In-Reply-To: <9881.1536846962@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox