Re: Comment simplehash/dynahash trade-offs

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Comment simplehash/dynahash trade-offs
Дата
Msg-id CA+hUKG+eMUrNwhekzuGP2NQrKUYY=MteVfCdoO8VUBWbPc3CNA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Comment simplehash/dynahash trade-offs  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Comment simplehash/dynahash trade-offs  (David Rowley <dgrowleyml@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: TRUNCATE on foreign tables
Следующее
От: David Rowley
Дата:
Сообщение: Re: Comment simplehash/dynahash trade-offs