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

Re: [PATCHES] updated patch for selecting large results

From: Chris Mair <chrisnospam(at)1006(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] updated patch for selecting large results
Date: 2006-08-28 21:59:34
Message-ID: 1156802374.4026.94.camel@dell.home.lan (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
> Performance-wise I took for granted without checking that GetVariable's
> running time would be negligible.
> [looks at the code]
> I see it's it's basically two function calls with a loop over a linked
> list of values (in the order of 10) doing strcmps and one strtol.
> It is not quite clear to me what the impact of this is. I could
> imagine it would show up only if you perform lots of trivial queries
> through psql. I'm going to benchmark something now and report back.
> Anyway, regardless the benchmark, I feel it's somehow not clean to have
> a variable introduce a difference between "\g" and ";".
> [goes benchmarking...]

so I ran a file containing 1 million lines of "select 1;" through
psql (discarding the output). 5 runs each with the patch and with the
patch removed (the if() in SendQuery commented).

These are the results in seconds user time of psql on a Pentium M 2.0
GHz (real time was longer, since the postmaster process was on the same

 patch | count |   avg   |      stddev
 f     |     5 | 16.6722 | 0.359759919946455
 t     |     5 | 17.2762 | 0.259528803796329

The conclusion is that, yes, the overhead is measurable, albeit with
a very synthetic benchmark (of the type MySQL wins ;).

Basically I'm loosing 0.6 usec on each query line (when FETCH_COUNT
is not there and therefore psql need to scan the whole variables list
in GetVariable() for nothing).

Not sure if that's acceptable (I'd say yes, but then again, I'm
not a cycle counter type of programmer *cough* Java *cough* ;)...


Bye, Chris.


Chris Mair

In response to


pgsql-hackers by date

Next:From: Neil ConwayDate: 2006-08-28 22:07:21
Subject: Re: autovacuum causing numerous regression-test failures
Previous:From: Tatsuo IshiiDate: 2006-08-28 21:58:47
Subject: Re: Rtree circle ops

pgsql-patches by date

Next:From: Tom LaneDate: 2006-08-28 22:09:06
Subject: Re: [PATCHES] updated patch for selecting large results sets in
Previous:From: Joachim WielandDate: 2006-08-28 21:03:25
Subject: Re: [PATCHES] Another VPATH patch for ecpg

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