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

From David Rowley
Subject Re: Comment simplehash/dynahash trade-offs
Date
Msg-id CAApHDvrAp3Nv=qNzkM1Q_TfYStZaTNN6O=duyFTSrWtHcEj8Tw@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  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
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.

David

Attachment

pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Re: fixing pg_ctl with relative paths
Next
From: David Rowley
Date:
Subject: Re: Use of "long" in incremental sort code