Re: Reviving Time Travel (was Re: 'TID index')
От | Tom Lane |
---|---|
Тема | Re: Reviving Time Travel (was Re: 'TID index') |
Дата | |
Msg-id | 1410.1096585889@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Reviving Time Travel (was Re: 'TID index') (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Ответы |
Re: Reviving Time Travel (was Re: 'TID index')
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@dcc.uchile.cl> writes: > One idea would be to vacuum the page if it can be determined that the > relation doesn't have indexes. This information is generally not known, ... especially not by the page writer. You can't assume that you have access to the relation descriptor --- for instance, it's entirely possible that the bgwriter (or another backend) will need to push out a dirty page that belongs to a newly created relation for which the catalog data remains uncommitted. There are related scenarios involving uncommitted drops. More generally I think that invoking VACUUM processing from the bgwriter would be a serious violation of the module hierarchy, and would inflict more pain in the form of bugs and maintenance headaches than it could possibly be worth. We just this version managed to get smgr decoupled from the relcache, like it should have been all along. (bufmgr should be too, but I haven't tackled that yet...) This was actually a necessary step to make the separate bgwriter feasible. Let's not reverse that cleanup in pursuit of dubious optimizations. regards, tom lane
В списке pgsql-hackers по дате отправления: