From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Comment simplehash/dynahash trade-offs |
Date: | 2020-08-02 01:53:43 |
Message-ID: | CAApHDvrAp3Nv=qNzkM1Q_TfYStZaTNN6O=duyFTSrWtHcEj8Tw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2 Aug 2020 at 11:16, David Rowley <dgrowleyml(at)gmail(dot)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 | Content-Type | Size |
---|---|---|
simplehash_fix.patch | application/octet-stream | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-08-02 02:26:25 | Re: Use of "long" in incremental sort code |
Previous Message | Chapman Flack | 2020-08-02 00:51:54 | Re: Re: fixing pg_ctl with relative paths |