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

Re: Speed dblink using alternate libpq tuple storage

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>
To: markokr(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org, greg(at)2ndQuadrant(dot)com
Subject: Re: Speed dblink using alternate libpq tuple storage
Date: 2012-01-27 08:57:01
Message-ID: 20120127.175701.135957224.horiguchi.kyotaro@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Hello, This is a new version of the patch formerly known as
'alternative storage for libpq'.

- Changed the concept to 'Alternative Row Processor' from
  'Storage handler'. Symbol names are also changed.

- Callback function is modified following to the comment.

- From the restriction of time, I did minimum check for this
  patch. The purpose of this patch is to show the new implement.

- Proformance is not measured for this patch for the same
  reason. I will do that on next monday.

- The meaning of PGresAttValue is changed. The field 'value' now
  contains a value withOUT terminating zero. This change seems to
  have no effect on any other portion within the whole source
  tree of postgresql from what I've seen.


> > I would like to propose better one-shot API with:
> > 
> >     void *(*RowStoreHandler)(PGresult *res, PGresAttValue *columns);
...
> > 1) Pass-through processing do not need to care about unnecessary
> >    per-row allocations.
> > 
> > 2) Handlers that want to copy of the row (like regular libpq),
> >    can optimize allocations by having "global" view of the row.
> >    (Eg. One allocation for row header + data).

I expect the new implementation is far more better than the
orignal.

regargs,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment: dblink_use_rowproc_20120127.patch
Description: text/x-patch (11.5 KB)
Attachment: libpq_rowproc_doc_20120127.patch
Description: text/x-patch (6.0 KB)
Attachment: libpq_rowproc_20120127.patch
Description: text/x-patch (18.2 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Peter van HardenbergDate: 2012-01-27 09:46:50
Subject: Re: Inline Extension
Previous:From: Heikki LinnakangasDate: 2012-01-27 07:16:52
Subject: Re: BGWriter latch, power saving

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