Re: estimating # of distinct values
От | Robert Haas |
---|---|
Тема | Re: estimating # of distinct values |
Дата | |
Msg-id | AANLkTinnbTPG5zhyutQwzadZ-ku_irRTOjnnHP=bWzoc@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: estimating # of distinct values (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
On Tue, Jan 18, 2011 at 12:32 PM, Jim Nasby <jim@nasby.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 stillhas all the work that would be associated with vacuuming a table with the definition of a toast table. In fact, at onepoint vacuuming toast took two passes: the first deleted the toast rows that were no longer needed, then you had to goback 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 twotables 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
В списке pgsql-hackers по дате отправления: