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 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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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