Skip site navigation (1) Skip section navigation (2)

Re: Speed dblink using alternate libpq tuple storage

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: mmoncure(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, greg(at)2ndquadrant(dot)com
Subject: Re: Speed dblink using alternate libpq tuple storage
Date: 2012-02-01 14:19:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 01, 2012 at 11:52:27AM +0200, Marko Kreen wrote:
> Please wait a moment, I started doing small cleanups,
> and now have some larger ones too.  I'll send it soon.

I started doing small comment cleanups, but then the changes
spread out a bit...

Kyotaro-san, please review.  If you don't find anything to fix,
then it's ready for commiter, I think.


== dblink ==

- Increase area in bigger steps

- Fix realloc leak on failure

== libpq ==

- Replace dynamic stack array with malloced rowBuf on PGconn.
  It is only increased, never decreased.

- Made PGresult.rowProcessorErrMsg allocated with pqResultStrdup.
  Seems more proper.  Although it would be even better to
  use ->errmsg for it, but it's lifetime and usage
  are unclear to me.

- Removed the rowProcessor, rowProcessorParam from PGresult.
  They are unnecessary there.

- Move conditional msg outside from libpq_gettext()
- Removed the unnecessary memcpy() from pqAddRow

- Moved PQregisterRowProcessor to fe-exec.c, made pqAddRow static.

- Restored pqAddTuple export.

- Renamed few symbols:
  PQregisterRowProcessor -> PQsetRowProcessor
  RowProcessor -> PQrowProcessor
  Mes -> Msg  (more common abbreviation)

- Updated some comments

- Updated sgml doc

== Benchmark ==

I did try to benchmark whether the patch affects stock libpq usage.
But, uh, could not draw any conclusions.  It *seems* that patch is
bit faster with few columns, bit slower with many, but the difference
seems smaller than test noise.  OTOH, the test noise is pretty big,
so maybe I don't have stable-enough setup to properly benchmark.

As the test-app does not actually touch resultset, it seems probable
that application that actually does something with resultset,
will no see the difference.

It would be nice if anybody who has stable pgbench setup could
run few tests to see whether the patch moves things either way.

Just in case, I attached the minimal test files.


Attachment: libpq_rowproc_2012-02-01.diff
Description: text/x-diff (21.9 KB)
Attachment: libpq_rowproc_doc_2012-02-01.diff
Description: text/x-diff (6.0 KB)
Attachment: dblink_rowproc_2012-02-01.diff
Description: text/x-diff (13.4 KB)
Attachment: test_prog.c
Description: text/x-csrc (1.0 KB)

In response to

pgsql-hackers by date

Next:From: postgresDate: 2012-02-01 14:28:30
Subject: BUG #6425: Bus error in slot_deform_tuple
Previous:From: Josh KupershmidtDate: 2012-02-01 13:09:17
Subject: Re: Dry-run mode for pg_archivecleanup

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group