Re: trivial patch for dynahash logging

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: trivial patch for dynahash logging
Date: 2014-09-29 19:01:43
Message-ID: CAMkU=1y-fk=NR6KfYwG3RZp01TqR8Mfw1=cq3M9SrABL5X-dwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 27, 2014 at 3:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> > under HASH_STATISTICS, the output reporting "this HTAB" upon destruction
> is
> > pretty useless. Which HTAB would this one be? It is not necessarily the
> > most recently created one.
>
> > This makes it output the %p to the actual HTAB, so it can be matched up
> > with the logging of the creation.
>
> Seems reasonable, although I wonder why neither of them print the tabname
> string. More generally, I see no calls to hash_stats() anywhere except
> in hash_destroy(), so wouldn't you need a rather larger patch to make it
> actually do anything useful?
>

I also wondered about the tabname string. Maybe it didn't exist back when
this was added.

I'm not sure where else it should be called other than from hash_destroy.
But if I had a need to call it from elsewhere for some investigative
purpose, I would add the call there and recompile. Once the base
functionality is there, it is easy to enough to add invocations.

But just having it report at destruction was useful enough to convince me
that hash collisions were not the problem, and I had to look elsewhere (not
in dynahash) for this particular problem. That is a pretty useful thing to
know. I probably could have made the same conclusion without the %p, but
would not have had much confidence in it.

(For the curious, my tentative conclusion was that dynahash is as about as
efficient as can be expected here, but the bitmap index scan cost estimate
is overly optimistic about how efficient that is.)

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-09-29 19:07:45 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Josh Berkus 2014-09-29 18:53:29 Re: jsonb format is pessimal for toast compression