Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
