From: | "Alon Goldshuv" <agoldshuv(at)greenplum(dot)com> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Libpq COPY optimization |
Date: | 2006-01-08 14:00:04 |
Message-ID: | BFE6E785.BDC9%agoldshuv@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 PQputCopyData, not requiring
an alternate version of pqPutMsgEnd.
The change is that before returning, PQputCopyData would process inbound
NOTICEs *only if* the buffer was flushed. (and drop the other
PQconsumeInput/parseInput calls in PQputCopyData)
At the end of the copy operation, libpq's caller will call
PQputCopyEnd followed by PQgetResult. PQputCopyEnd flushes
the buffer, but I don't think we need to add any PQconsumeInput/
parseInput there, because any remaining inbound NOTICEs will be
handled immediately afterward when libpq's caller calls PQgetResult.
Alon.
Attachment | Content-Type | Size |
---|---|---|
interrupt-checking-patch-for-libpq.patch.txt | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2006-01-08 14:05:15 | Re: stat /etc/localtime 38000 times on startup? |
Previous Message | Andrew Dunstan | 2006-01-08 13:52:53 | stat /etc/localtime 38000 times on startup? |