Re: Really dumb planner decision

От: Kevin Grittner
Тема: Re: Really dumb planner decision
Дата: ,
Msg-id: 49E6F632.EE98.0025.0@wicourts.gov
(см: обсуждение, исходный текст)
Ответ на: Re: Really dumb planner decision  (Tom Lane)
Ответы: Re: Really dumb planner decision  (Merlin Moncure)
Список: pgsql-performance

Скрыть дерево обсуждения

Really dumb planner decision  (Matthew Wakeling, )
 Re: Really dumb planner decision  (Grzegorz Jaśkiewicz, )
  Re: Really dumb planner decision  (Matthew Wakeling, )
   Re: Really dumb planner decision  (Robert Haas, )
    Re: Really dumb planner decision  (Matthew Wakeling, )
     Re: Really dumb planner decision  (Merlin Moncure, )
      Re: Really dumb planner decision  (Tom Lane, )
       Re: Really dumb planner decision  ("Kevin Grittner", )
        Re: Really dumb planner decision  (Merlin Moncure, )
       Re: Really dumb planner decision  (Robert Haas, )
        Re: Really dumb planner decision  (Matthew Wakeling, )
         Re: Really dumb planner decision  (Tom Lane, )
 Re: Really dumb planner decision  (Grzegorz Jaśkiewicz, )
  Re: Really dumb planner decision  (Matthew Wakeling, )

Tom Lane <> wrote:
> Bear in mind that those limits exist to keep you from running into
> exponentially increasing planning time when the size of a planning
> problem gets big.  "Raise 'em to the moon" isn't really a sane
strategy.
> It might be that we could get away with raising them by one or two
given
> the general improvement in hardware since the values were last
looked
> at; but I'd be hesitant to push the defaults further than that.

I also think that there was a change somewhere in the 8.2 or 8.3 time
frame which mitigated this.  (Perhaps a change in how statistics were
scanned?)  The combination of a large statistics target and higher
limits used to drive plan time through the roof, but I'm now seeing
plan times around 50 ms for limits of 20 and statistics targets of
100.  Given the savings from the better plans, it's worth it, at least
in our case.

I wonder what sort of testing would be required to determine a safe
installation default with the current code.

-Kevin


В списке pgsql-performance по дате сообщения:

От: Matthew Wakeling
Дата:
Сообщение: Re: GiST index performance
От: Kris Jurka
Дата:
Сообщение: No hash join across partitioned tables?