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 по дате отправления: