Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> On 14.08.2011 01:13, Tom Lane wrote:
>> I am thinking that the most reasonable solution is instead to fix VACUUM
>> FULL/CLUSTER so that they don't change existing toast item OIDs when
>> vacuuming a system catalog. They already do some pretty ugly things to
>> avoid changing the toast table's OID in this case, and locking down the
>> item OIDs too doesn't seem that much harder. (Though I've not actually
>> looked at the code yet...)
> How about detoasting all datums before caching them? It's surprising
> that a datum that is supposedly in a catalog cache, actually needs disk
> access to use.
Don't really want to fix a VACUUM-FULL-induced problem by inserting
distributed overhead into every other operation.
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.
There's also a concern of bloating the catcaches if we do that ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
