Re: Improvement of procArray.xmin for VACUUM
От | Bruce Momjian |
---|---|
Тема | Re: Improvement of procArray.xmin for VACUUM |
Дата | |
Msg-id | 200703270050.l2R0omk14530@momjian.us обсуждение исходный текст |
Ответ на | Re: Improvement of procArray.xmin for VACUUM (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Improvement of procArray.xmin for VACUUM
|
Список | pgsql-patches |
Gregory Stark wrote: > > 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? Interesting idea. If the table had triggers, it would need a snapshot, but if not, yea, that is certainly possible. --------------------------------------------------------------------------- > > "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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: