> > 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.
More accurately, that 3 or 4% overhead is added to about all queries
(we're talking *psql*-only running time).
It's just that for anything but short queries, psql running time
totally dwarfs regarding to postmaster running time anyway.
> 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 ...
Might help.
Take into account the strtol is not critical at all for FETCH_COUNT,
since when it's actually set, we're supposed to retrieving big data
where a strtol doesn't matter anyway. The overhead comes from scanning
the linked list for nothing in the normal case (when it's not set).
I don't know how the other uses factor in here, but I see it's called
at least twice more on average calls to SendQuery.
Bye,
Chris.
--
Chris Mair
http://www.1006.org
