Re: Comment simplehash/dynahash trade-offs

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: Re: fixing pg_ctl with relative paths
Следующее
От: David Rowley
Дата:
Сообщение: Re: Use of "long" in incremental sort code