Re: Improvement of procArray.xmin for VACUUM
От | Gregory Stark |
---|---|
Тема | Re: Improvement of procArray.xmin for VACUUM |
Дата | |
Msg-id | 877it3leb3.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Improvement of procArray.xmin for VACUUM (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Improvement of procArray.xmin for VACUUM
|
Список | pgsql-patches |
I have a question about what would happen for a transaction running a command like COPY FROM. Is it possible it would manage to arrange to have no live snapshots at all? So it would have no impact on concurrent VACUUMs? What about something running a large pg_restore? "Tom Lane" <tgl@sss.pgh.pa.us> writes: > On the whole though I think we should let this idea go till 8.4; I tend to agree but for a different reason. I think it's something that will open the doors for a lot of new ideas. If we put it in CVS HEAD early in 8.4 I think (or hope at any rate) we'll think of at least a few new things we can do with the new more precise information it exposes. Just as an example, if you find you have no live snapshots can you throw out the combocid hash? Any tuple you find with a combocid that's been discarded that way must predate your current scan and therefore is deleted for you. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: