Re: BufferAlloc: don't take two simultaneous locks

Поиск
Список
Период
Сортировка
От Michail Nikolaev
Тема Re: BufferAlloc: don't take two simultaneous locks
Дата
Msg-id CANtu0ohTqkVYCFyHRM6uG=jO=j_9MkQMrh04YPVt57rL5sTykA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BufferAlloc: don't take two simultaneous locks  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: BufferAlloc: don't take two simultaneous locks  (Michail Nikolaev <michail.nikolaev@gmail.com>)
Список pgsql-hackers
Hello, Yura.

Test results look promising. But it seems like the naming and dynahash
API change is a little confusing.

1) I think it is better to split the main part and atomic nentries
optimization into separate commits.
2) Also, it would be nice to also fix hash_update_hash_key bug :)
3) Do we really need a SIZEOF_LONG check? I think pg_atomic_uint64 is
fine these days.
4) Looks like hash_insert_with_hash_nocheck could potentially break
the hash table. Is it better to replace it with
hash_search_with_hash_value with HASH_ATTACH action?
5) In such a case hash_delete_skip_freelist with
hash_search_with_hash_value with HASH_DETTACH.
6) And then hash_return_to_freelist -> hash_dispose_dettached_entry?

Another approach is a new version of hash_update_hash_key with
callbacks. Probably it is the most "correct" way to keep a hash table
implementation details closed. It should be doable, I think.

Thanks,
Michail.



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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Why is INSERT-driven autovacuuming based on pg_class.reltuples?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Support tab completion for upper character inputs in psql