Re: Speed up transaction completion faster after many relations are accessed in a transaction - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Speed up transaction completion faster after many relations are accessed in a transaction
Date
Msg-id 21531.1554653380@sss.pgh.pa.us
Whole thread Raw
In response to Re: Speed up transaction completion faster after many relations areaccessed in a transaction  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Speed up transaction completion faster after many relations areaccessed in a transaction
Re: Speed up transaction completion faster after many relations areaccessed in a transaction
List pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> Okay.  Here's another version with all the average locks code removed
> that only recreates the table when it's completely empty.

Um ... I don't see where you're destroying the old hash?

Also, I entirely dislike wiring in assumptions about hash_seq_search's
private state structure here.  I think it's worth having an explicit
entry point in dynahash.c to get the current number of buckets.

Also, I would not define "significantly bloated" as "the table has
grown at all".  I think the threshold ought to be at least ~100
buckets, if we're starting at 16.

Probably we ought to try to gather some evidence to inform the
choice of cutoff here.  Maybe instrument the regression tests to
see how big the table typically gets?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ToDo: show size of partitioned table
Next
From: Alvaro Herrera
Date:
Subject: Re: query logging of prepared statements