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 <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Really dumb planner decision
|
Список | pgsql-performance |
Tom Lane <tgl@sss.pgh.pa.us> 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 по дате отправления: