Re: [PATCHES] updated patch for selecting large results sets in
| От | Tom Lane |
|---|---|
| Тема | Re: [PATCHES] updated patch for selecting large results sets in |
| Дата | |
| Msg-id | 19044.1156802946@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [PATCHES] updated patch for selecting large results (Chris Mair <chrisnospam@1006.org>) |
| Ответы |
Re: [PATCHES] updated patch for selecting large results
|
| Список | 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 по дате отправления: