On Sun, Aug 14, 2011 at 5:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > There would be some merit in your suggestion if we knew that all/most > toasted columns would actually get fetched out of the catcache entry > at some point. Then we'd only be moving the cost around, and might even > save something on repeated accesses. But I don't think we know that. > In the specific example at hand (pg_statistic entries) it's entirely > plausible that the planner would only need the histogram, or only need > the MCV list, depending on the sorts of queries it was coping with.
Fwiw detoasting statistics entries sounds like a fine idea to me. I've often seen queries that are unexpectedly slow to plan and chalked it up to statistics entries getting toasted. If it's ok to read either the histogram or MVC list from disk every time we plan a query then why are we bothering with an in-memory cache of the statistics at all? The only thing that gives me pause is that it's possible these entries are *really* large. If you have a decent number of tables that are all a few megabytes of histograms then things could go poorly. But I don't think having to read in these entries from pg_toast every time you plan a query is going to go much better for you either. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
