Re: Flushing large data immediately in pqcomm
От | David Rowley |
---|---|
Тема | Re: Flushing large data immediately in pqcomm |
Дата | |
Msg-id | CAApHDvoD_K0vojCO7QKyR8+=ZJXCv2tFy=n2MQ4c5+cXjvVt0A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Flushing large data immediately in pqcomm (Jelte Fennema-Nio <postgres@jeltef.nl>) |
Список | pgsql-hackers |
On Thu, 21 Mar 2024 at 22:44, Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > > On Thu, 21 Mar 2024 at 01:45, David Rowley <dgrowleyml@gmail.com> wrote: > > As I understand the code, there's no problem calling > > internal_flush_buffer() when the buffer is empty and I suspect that if > > we're sending a few buffers with "len > PqSendBufferSize" that it's > > just so unlikely that the buffer is empty that we should just do the > > function call and let internal_flush_buffer() handle doing nothing if > > the buffer really is empty. I think the chances of > > internal_flush_buffer() having to do exactly nothing here is less than > > 1 in 8192, so I just don't think the check is worthwhile. > > I think you're missing the exact case that we're trying to improve > here: Calls to internal_putbytes with a very large len, e.g. 1MB. > With the new code the buffer will be empty ~50% of the time (not less > than 1 in 8192) with such large buffers, because the flow that will > happen: It was the code I misread. I understand what the aim is. I failed to notice the while loop in internal_putbytes(). So what I mentioned about trying to fill the buffer before flushing already happens. I now agree that the PqSendStart == PqSendPointer test. I'd say since the reported regression was with 100 byte rows that testing "len >= PqSendBufferSize" before PqSendStart == PqSendPointer makes sense. David
В списке pgsql-hackers по дате отправления: