Re: Flushing large data immediately in pqcomm

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Flushing large data immediately in pqcomm
Дата
Msg-id 20240407013917.r5o7qd7flgnepo2n@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Flushing large data immediately in pqcomm  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Ответы Re: Flushing large data immediately in pqcomm
Re: Flushing large data immediately in pqcomm
Список pgsql-hackers
Hi,

On 2024-04-07 00:45:31 +0200, Jelte Fennema-Nio wrote:
> On Sat, 6 Apr 2024 at 22:21, Andres Freund <andres@anarazel.de> wrote:
> > The small regression for small results is still kinda visible, I haven't yet
> > tested the patch downthread.
> 
> Thanks a lot for the faster test script, I'm also impatient. I still
> saw the small regression with David his patch. Here's a v6 where I
> think it is now gone. I added inline to internal_put_bytes too. I
> think that helped especially because for two calls to
> internal_put_bytes len is a constant (1 and 4) that is smaller than
> PqSendBufferSize. So for those calls the compiler can now statically
> eliminate the new codepath because "len >= PqSendBufferSize" is known
> to be false at compile time.

Nice.


> Also I incorporated all of Ranier his comments.

Changing the global vars to size_t seems mildly bogus to me. All it's
achieving is to use slightly more memory. It also just seems unrelated to the
change.

Greetings,

Andres Freund



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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Streaming read-ready sequential scan code
Следующее
От: John Naylor
Дата:
Сообщение: Re: Change GUC hashtable to use simplehash?