Hello Simon,
Can you please provide the test cases that you used to plot the performance
graph you've attached.
Also do you know if your optimization will be useful for a very large amount
of subtransactions per transaction (around 1000)?
--
Thanks,
Yaroslav
On Thu, 4 Aug 2022 at 13:11, Simon Riggs wrote:
> I will post my patch, when complete, in a different thread.
To avoid confusion, I will withdraw this patch from the CF, in favour
of my other patch on a similar topic,
Minimizing calls to SubTransSetParent()
https://commitfest.postgresql.org/39/3
On Wed, Aug 3, 2022 at 4:14 PM Andres Freund wrote:
> I don't think this scenario would fundamentally change - we already keep the
> set of subxids in backend local memory (e.g. either a dedicated
> TransactionStateData or an element in ->childXids) and in the locking table
> (via XactLockTableIns
On Wed, 3 Aug 2022 at 20:18, Andres Freund wrote:
> On 2022-08-01 17:42:49 +0100, Simon Riggs wrote:
> > The reason for the slowdown is clear: when we overflow we check every
> > xid against subtrans, producing a large stream of lookups. Some
> > previous hackers have tried to speed up subtrans -
Hi,
On 2022-08-03 15:36:40 -0400, Robert Haas wrote:
> On Wed, Aug 3, 2022 at 3:18 PM Andres Freund wrote:
> > In contrast to e.g. clog or multixact we don't need to access a lot of old
> > While we can't put a useful hard cap on the number of potential subtrans
> > entries (we can only throw sub
On Wed, Aug 3, 2022 at 3:18 PM Andres Freund wrote:
> In contrast to e.g. clog or multixact we don't need to access a lot of old
> While we can't put a useful hard cap on the number of potential subtrans
> entries (we can only throw subxid->parent mappings away once no existing
> snapshot might ne
Hi,
On 2022-08-01 17:42:49 +0100, Simon Riggs wrote:
> The reason for the slowdown is clear: when we overflow we check every
> xid against subtrans, producing a large stream of lookups. Some
> previous hackers have tried to speed up subtrans - this patch takes a
> different approach: remove as man
On Mon, Aug 1, 2022 at 10:13 PM Simon Riggs
wrote:
>
> "A mathematical catastrophe is a point in a model of an input-output
> system, where a vanishingly small change in the input can produce a
> large change in the output."
>
> We have just such a change in Postgres: when a snapshot overflows. In
