Re: Our trial to TPC-DS but optimizer made unreasonable plan - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Our trial to TPC-DS but optimizer made unreasonable plan
Date
Msg-id CA+Tgmobe7UztQNTdFED8_XNOg7PmaSG578z2PQMsqXq_hi+wBQ@mail.gmail.com
Whole thread Raw
In response to Re: Our trial to TPC-DS but optimizer made unreasonable plan  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
On Mon, Aug 17, 2015 at 9:40 AM, Kouhei Kaigai <kaigai@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.

It's possible that this can work, but it might be a good idea to run
'perf' on this query and find out where the CPU time is actually
going.  That might give you a clearer picture of why the HashAggregate
is slow.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Robert Haas
Date:
Subject: Re: Configure with thread sanitizer fails the thread test