On Mon, 8 Apr 2019 at 02:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I like the concept ... but the particular implementation, not so much.
> It seems way overcomplicated. In the first place, why should we
> add code to copy entries? Just don't do it except when the table
> is empty. In the second, I think we could probably have a far
> cheaper test for how big the table is --- maybe we'd need to
> expose some function in dynahash.c, but the right way here is just
> to see how many buckets there are. I don't like adding statistics
> counting for this, because it's got basically nothing to do with
> what the actual problem is. (If you acquire and release one lock,
> and do that over and over, you don't have a bloat problem no
> matter how many times you do it.)
hash_get_num_entries() looks cheap enough to me. Can you explain why
you think that's too expensive?
> LockMethodLocalHash is special in that it predictably goes to empty
> at the end of every transaction, so that de-bloating at that point
> is a workable strategy. I think we'd probably need something more
> robust if we were trying to fix this generally for all hash tables.
> But if we're going to go with the one-off hack approach, we should
> certainly try to keep that hack as simple as possible.
As cheap as possible sounds good, but I'm confused at why you think
the table will always be empty at the end of transaction. It's my
understanding and I see from debugging that session level locks remain
in there. If I don't copy those into the new table they'll be lost.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services