Re: Comment simplehash/dynahash trade-offs - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Comment simplehash/dynahash trade-offs
Date
Msg-id CA+hUKG+eMUrNwhekzuGP2NQrKUYY=MteVfCdoO8VUBWbPc3CNA@mail.gmail.com
Whole thread Raw
In response to Re: Comment simplehash/dynahash trade-offs  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Comment simplehash/dynahash trade-offs
List pgsql-hackers
On Sun, Aug 2, 2020 at 1:54 PM David Rowley <dgrowleyml@gmail.com> wrote:
> On Sun, 2 Aug 2020 at 11:16, David Rowley <dgrowleyml@gmail.com> wrote:
> > Maybe it would be better just to get rid of the enum and just #define
> > the values. It seems unlikely that we're every going to need many more
> > states than what are there already, let along more than, say 127 of
> > them. It does look like manifest_file could be shrunk down a bit too
> > by making the status field a char.
>
> This didn't turn out quite as pretty as I had imagined.  I needed to
> leave the two statuses defined in simplehash.h so that callers could
> make use of them. (Result Cache will do this).
>
> The change here would be callers would need to use SH_STATUS_IN_USE
> rather than <prefix>_SH_IN_USE.
>
> I'm not really that sold on doing things this way. I really just don't
> want to have to make my status field a uint32 in Result Cache per what
> the new comment states we must do. If there's a nicer way, then
> perhaps that's worth considering.

Agreed that the new comment is wrong and should be changed.

I think you can probably go further, though, and make it require no
storage at all by making it optionally "intrusive", by using a special
value in an existing member, and supplying an expression to set and
test for that value.  For example, maybe some users have a pointer but
never want to use NULL, and maybe some users already have a field
holding various flags that are one bit wide and can spare a bit.



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: TRUNCATE on foreign tables
Next
From: David Rowley
Date:
Subject: Re: Comment simplehash/dynahash trade-offs