Re: Libpq COPY optimization

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alon Goldshuv <agoldshuv(at)greenplum(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Libpq COPY optimization
Date: 2006-01-23 20:20:05
Message-ID: 200601232020.k0NKK5i11674@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Can I get an updated patch for this?

---------------------------------------------------------------------------

Tom Lane wrote:
> "Alon Goldshuv" <agoldshuv(at)greenplum(dot)com> 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 pqSendSome routine does that.
> That makes the PQconsumeInput call in PQputCopyData redundant (or
> almost; see below). The parseInput call is still needed, because it's
> there to pull NOTICE messages out of the input buffer and get rid of
> them, rather than possibly having the input buffer grow to exceed
> memory. But when there's nothing for it to do, parseInput is cheap
> enough that there's no real need to bypass it.
>
> In short, if you just remove the PQconsumeInput call I think you'll find
> that it does what you want.
>
> The only case where it's helpful to have it there is if there's a
> incomplete message in the input buffer, as parseInput isn't quite so
> fast if it has to determine that the message is incomplete. Without
> the PQconsumeInput call, the incomplete-message state could persist
> for a long time, and you'd pay the parseInput overhead each time through
> PQputCopyData. However, that's certainly not the normal situation,
> so I think we could leave that case slightly pessimal. It's certainly
> true that that path in parseInput is a lot faster than a kernel call,
> so it'd still be better than it is now.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adnan HOTMAIL 2006-01-23 22:07:06 unsubscribe
Previous Message Greg Stark 2006-01-23 20:19:19 Re: ROLLBACK triggers?