Re: Our trial to TPC-DS but optimizer made unreasonable plan

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Our trial to TPC-DS but optimizer made unreasonable plan
Date: 2015-08-20 01:21:41
Message-ID: CAM3SWZRRCs6KAyN-bDsh0_pG=8xm3fvcF1X9dLsVd3wVbt1pHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 19, 2015 at 6:08 PM, Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
> Indeed, 6 of 8 grouping keys in this query uses bpchar() data type, so it is
> natural comparison function consumed larger portion of CPU cycles.
> Do we have any idea to assist these queries by the backend?

With abbreviated keys, char(n) is very significantly slower than
varchar(n) (or text). I've been meaning to revisit my docpatch to warn
users of this (we already specifically advise against using char(n),
more or less). Abbreviation and a few other tricks could easily make
an enormous difference.

There is no very good reason why the same optimizations that I applied
to text could not also be applied to bpchar(), I think. I think that
abbreviation could remove much of the special char(n) effort, as well;
someone simply needs to do the work. I'm actually more concerned about
the problems that this causes for third-party benchmarks than I am
about the problems for real users.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-08-20 01:49:46 Re: PATCH: use foreign keys to improve join estimates v1
Previous Message Kouhei Kaigai 2015-08-20 01:08:57 Re: Our trial to TPC-DS but optimizer made unreasonable plan