Re: Optimizer picks an ineffient plan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimizer picks an ineffient plan
Дата
Msg-id 20886.1062657185@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Optimizer picks an ineffient plan  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Optimizer picks an ineffient plan
Re: Optimizer picks an ineffient plan
Список pgsql-general
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Yes, that's the real crux of the matter.  Should the optimizer spend
>> cycles on *every* query to detect cases where the user has written
>> useless sort keys?  I've got grave doubts that it's a win.

> Well I'm sure the same arguments were made 30 years ago about optimizing
> compilers. But thankfully the optimizer-geeks won the argument.

Um ... I *am* an optimizer-geek.  You can find my name in the credits
for Bliss/11, which was the best optimizing compiler on the planet about
thirty years ago.  I stand by my comment that there's a tradeoff between
the potential gain from an optimization and the time spent to find it.

PG is at a disadvantage compared to typical compilation scenarios, in
that a compiler assumes its output will be executed many times, while
SQL queries often are planned and then executed but once.  There's been
some talk of working harder when planning a "prepared statement", but
so far I've not seen very many places where I'd really want to alter
the planner's behavior on that basis.

            regards, tom lane

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

Предыдущее
От: rolf.ostvik@axxessit.no
Дата:
Сообщение: Re: Using oids
Следующее
От: Andreas Muck
Дата:
Сообщение: More than 1024 connections from the same c-backend