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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Our trial to TPC-DS but optimizer made unreasonable plan
Дата
Msg-id CAM3SWZRRCs6KAyN-bDsh0_pG=8xm3fvcF1X9dLsVd3wVbt1pHw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Our trial to TPC-DS but optimizer made unreasonable plan  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
On Wed, Aug 19, 2015 at 6:08 PM, Kouhei Kaigai <kaigai@ak.jp.nec.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Our trial to TPC-DS but optimizer made unreasonable plan
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: use foreign keys to improve join estimates v1