On Mon, Aug 17, 2015 at 6:40 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > I think SortSupport logic provides a reasonable way to solve this > kind of problem. For example, btint4sortsupport() informs a function > pointer of the fast version of comparator (btint4fastcmp) which takes > two Datum argument without indirect memory reference. > This mechanism will also make sense for HashAggregate logic, to reduce > the cost of function invocations. > > Please comment on the idea I noticed here.
Is this a 9.5-based system? If so, then you'd benefit from the memcmp() pre-check within varstr_cmp() by being on 9.5, since the pre-check is not limited to cases that use text/varchar SortSupport -- this could make a big difference here. If not, then it might be somewhat helpful to add a pre-check that considers total binary equality only before bcTruelen() is ever called. Not so sure about the latter idea, though. I'm not sure if it would help with hash aggregates to use something like SortSupport to avoid fmgr overhead. It might make enough of a difference to matter, but maybe the easier win would come from considering simple binary equality first, and only then using an equality operator (think HOT style checks). That would have the advantage of requiring no per-type/operator class support at all, since it's safe to assume that binary equality is a proxy for "equivalence" of sort order (or whatever we call the case where 5.00::numeric and 5.000::numeric are considered equal). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
