> > 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
