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 22:38:49 |
Message-ID: | 1156804729.4026.123.camel@dell.home.lan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2006-08-28 22:39:35 | Re: autovacuum causing numerous regression-test failures |
Previous Message | Tom Lane | 2006-08-28 22:16:01 | Re: Rtree circle ops |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-08-28 22:47:31 | Re: [HACKERS] Performance testing of COPY (SELECT) |
Previous Message | Tom Lane | 2006-08-28 22:09:06 | Re: [PATCHES] updated patch for selecting large results sets in |