Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers
From | Kyotaro HORIGUCHI |
---|---|
Subject | Re: Speed dblink using alternate libpq tuple storage |
Date | |
Msg-id | 20120221.184234.06202468.horiguchi.kyotaro@oss.ntt.co.jp Whole thread Raw |
In response to | Re: Speed dblink using alternate libpq tuple storage (Marko Kreen <markokr@gmail.com>) |
Responses |
Re: Speed dblink using alternate libpq tuple storage
Re: Speed dblink using alternate libpq tuple storage |
List | pgsql-hackers |
Hello, > > I don't have any attachment to PQskipRemainingResults(), but I > > think that some formal method to skip until Command-Complete('C') > > without breaking session is necessary because current libpq does > > so. > > We have such function: PQgetResult(). Only question is how > to flag that the rows should be dropped. I agree with it. I did this by conn->result->resultStatus == PGRES_FATAL_ERROR that instructs pqParseInput[23]() to skip calling getAnotherTuple() but another means to do the same thing without marking error is needed. > Also, as row handler is on connection, then changing it's > behavior is connection context, not result. OK, current implement copying the pointer to the row processor from PGconn to PGresult and getAnotherTuple() using it on PGresult to avoid unintended replacement of row processor by PQsetRowProcessor(), and I understand that row processor setting should be in PGconn context and the change by PGsetRowProcessor() should immediately become effective. That's right? > Ok, lets see how it looks. But please do it like this: > > - PQgetRowProcessor() that returns existing row processor. This seems also can be done by the return value of PQsetRowProcessor() (currently void). Anyway, I provide this function and also change the return value of PQsetRowProcessor(). > - PQskipResult() that just replaces row processor, then calls > PQgetResult() to eat the result. It's behaviour fully > matches PQgetResult() then. There seems to be two choices, one is that PQskipResult() replaces the row processor with NULL pointer and getAnotherTuple() calls row processor if not NULL. And the another is PQskipResult() sets the empty function as row processor. I do the latter for the present. This approach does needless call of getAnotherTuple(). Seeing if the pointer to row processor is NULL in pqParseInput[23]() could avoid this extra calls and may reduce the time for skip, but I think it is no need to do so for such rare cases. > I guess the main thing that annoys me with skipping is that > it would require additional magic flag inside libpq. > With PQgetRowProcessor() it does not need anymore, it's > just a helper function that user can implement as well. Ok. > Only question here is what should happen if there are > several incoming resultsets (several queries in PQexec). > Should we leave to user to loop over them? > > Seems there is 2 approaches here: > > 1) int PQskipResult(PGconn) > 2) int PQskipResult(PGconn, int skipAll) > > Both cases returning: > 1 - got resultset, there might be more > 0 - PQgetResult() returned NULL, connection is empty > -1 - error > > Although 1) mirrors regular PGgetResult() better, most users > might not know that function as they are using sync API. > They have simpler time with 2). So 2) then? Let me confirm the effects of this function. Is the below description right? - PQskipResult(conn, false) makes just following PQgetResult() to skip current bunch of rows and the consequent PQgetResult()'sgathers rows as usual. - PQskipResult(conn, true) makes all consequent PQgetResult()'s to skip all the rows. If this is right, row processor should stay also in PGresult context. PQskipResult() replaces the row processor in PGconn when the second parameter is true, and in PGresult for false. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
pgsql-hackers by date: