Re: estimating # of distinct values

On Tue, Jan 18, 2011 at 12:32 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>> How's that different from what vacuum does on a TOAST table now?
>
> TOAST vacuum is currently an entirely separate vacuum. It might run at the same time as the main table vacuum, but it still has all the work that would be associated with vacuuming a table with the definition of a toast table. In fact, at one point vacuuming toast took two passes: the first deleted the toast rows that were no longer needed, then you had to go back and vacuum those deleted rows.

I don't know whether it still works that way or not, but if it does,
fixing it could perhaps be done with far less drastic surgery than
what you're proposing here.

>>> Possibly, but you'd be paying tuple overhead twice, which is what I was looking to avoid with forks.
>>
>> What exactly do you mean by "tuple overhead"?
>
> typedef struct HeapTupleHeaderData. With only two tables it might not be that bad, depending on the fields. Beyond two tables it's almost certainly a loser.

A struct definition by itself doesn't cause overhead. Are you talking
about storage on disk? CPU usage for MVCC visibility testing?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company