I'll send it to -patches shortly
Alon.
On 1/23/06 10:20 PM, "Bruce Momjian" wrote:
>
> Can I get an updated patch for this?
>
> ---
>
> Tom Lane wrote:
>> "Alon Goldshuv" <[EMAIL PROTECTED]> writes:
>>> Please help me u
Can I get an updated patch for this?
---
Tom Lane wrote:
> "Alon Goldshuv" <[EMAIL PROTECTED]> writes:
> > Please help me understand this better. It appears to me that when the
> > client->backend pipe fills up, pqSendSome()
"Alon Goldshuv" <[EMAIL PROTECTED]> writes:
> Please help me understand this better. It appears to me that when the
> client->backend pipe fills up, pqSendSome() consumes any incoming
> NOTICE/WARNING messages before waiting, which should prevent deadlock.
Hm, I had forgotten that the low-level pq
Tom,
> It's not enough better, because it will still deadlock given a
> sufficiently large message-to-send. I don't think you can postpone
> the clearing-input action until after all the data is sent.
>
> regards, tom lane
Please help me understand this better. It appears to me that when the
cl
"Alon Goldshuv" <[EMAIL PROTECTED]> writes:
> The following is a suggestion for optimizing the libpq COPY FROM call for
> better performance. I submitted a similar suggestion awhile ago, but it
> wasn't safe enough. This one is better.
It's not enough better, because it will still deadlock given a
Title: Re: [HACKERS] Libpq COPY optimization
A note on this – we see a huge performance benefit from this change on Solaris, so much so that it should be mandatory for that platform. Solaris’ error handling is deeper, and so the repeated redundant interrupts that this patch avoids causes 60
The following is a suggestion for optimizing the libpq COPY FROM call for
better performance. I submitted a similar suggestion awhile ago, but it
wasn't safe enough. This one is better. It shows a pretty significant
improvement while maintaining deadlock prevention.
The change is localized to PQpu
