Re: Change GUC hashtable to use simplehash?

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Change GUC hashtable to use simplehash?
Дата
Msg-id 92f69b1ecc8f49a5a6c961edbdfe53c80000f484.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Change GUC hashtable to use simplehash?  (Gurjeet Singh <gurjeet@singh.im>)
Ответы Re: Change GUC hashtable to use simplehash?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Change GUC hashtable to use simplehash?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Fri, 2023-11-17 at 13:22 -0800, Gurjeet Singh wrote:
> This is not a comment on the patch itself, but since GUC operations
> are not typically considered performance or space sensitive,

A "SET search_path" clause on a CREATE FUNCTION is a case for better
performance in guc.c, because it repeatedly sets and rolls back the
setting on each function invocation.

Unfortunately, this patch doesn't really improve the performance. The
reason the hash table in guc.c is slow is because of the case folding
in both hashing and comparison. I might get around to fixing that,
which could have a minor impact, and perhaps then the choice between
hsearch/simplehash would matter.

> this
> comment from simplehash.h makes a case against it.
>
>  *      It's probably not worthwhile to generate such a specialized
> implementation
>  *      for hash tables that aren't performance or space sensitive.
>
> But your argument of a nicer API might make a case for the patch.

Yeah, that's what I was thinking. simplehash is newer and has a nicer
API, so if we like it and want to move more code over, this is one
step. But if we are fine using both hsearch.h and simplehash.h for
overlapping use cases indefinitely, then I'll drop this.

Regards,
    Jeff Davis




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Lifetime of commit timestamps
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Change GUC hashtable to use simplehash?