Re: Why does bootstrap and later initdb stages happen via client?

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Why does bootstrap and later initdb stages happen via client?
Дата
Msg-id c52c0ea8-6cf6-1679-006d-329d9dbf97a3@enterprisedb.com
обсуждение исходный текст
Список pgsql-hackers
On 08.09.21 21:07, Andres Freund wrote:
> There of course is historical raisins for things happening in initdb - the
> setup logic didn't use to be C. But now that it is C, it seems a bit absurd to
> read bootstrap data in initdb, write the data to a pipe, and then read it
> again in the backend. It for sure doesn't make things faster.

A couple of things I was looking into a while ago:  We could probably 
get a bit of performance by replacing the line-by-line substitutions 
(replace_token()) by processing the whole buffer at once.  And we could 
get even more performance by not doing any post-processing of the files 
at all.  For example, we don't need to replace_token() SIZEOF_POINTER, 
which is known at compile time.  Handling ENCODING, LC_COLLATE, etc. is 
not quite as obvious, but moving some of that logic into the backend 
could be helpful in that direction.



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

Предыдущее
От: Christoph Berg
Дата:
Сообщение: trap instead of error on 32 TiB table
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: drop tablespace failed when location contains .. on win32