Re: [PATCHES] updated patch for selecting large results sets in - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] updated patch for selecting large results sets in
Date
Msg-id 19044.1156802946@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] updated patch for selecting large results  (Chris Mair <chrisnospam@1006.org>)
Responses Re: [PATCHES] updated patch for selecting large results
List pgsql-hackers
Chris Mair <chrisnospam@1006.org> writes:
> The conclusion is that, yes, the overhead is measurable, albeit with
> a very synthetic benchmark (of the type MySQL wins ;).

OK, so about 3 or 4% overhead added to extremely short queries.
That's not enough to kill this patch, but it's still annoying ...
and as I mentioned, there are some existing calls of GetVariable
that are executed often enough to be a problem too.

It strikes me that having to do GetVariable *and* strtol and so on
for these special variables is pretty silly; the work should be done
during the infrequent times they are set, rather than the frequent
times they are read.  I propose that we add the equivalent of a GUC
assign_hook to psql's variable facility, attach an assign hook function
to each special variable, and have the assign hook transpose the
value into an internal variable that can be read with no overhead.
If we do that then the cost of the FETCH_COUNT patch will be
unmeasurable, and I think we'll see a few percent savings overall in
psql runtime from improving the existing hotspot uses of GetVariable.

Barring objections, I'll hack on this this evening ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Rtree circle ops
Next
From: Alvaro Herrera
Date:
Subject: Re: autovacuum causing numerous regression-test failures