Re: PostgreSQL clustering VS MySQL clustering
От | Tatsuo Ishii |
---|---|
Тема | Re: PostgreSQL clustering VS MySQL clustering |
Дата | |
Msg-id | 20050125.231917.35659109.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: PostgreSQL clustering VS MySQL clustering (Hannu Krosing <hannu@tm.ee>) |
Список | pgsql-performance |
> > > Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > > > Probably VACUUM works well for small to medium size tables, but not > > > > for huge ones. I'm considering about to implement "on the spot > > > > salvaging dead tuples". > > > > > > That's impossible on its face, except for the special case where the > > > same transaction inserts and deletes a tuple. In all other cases, the > > > transaction deleting a tuple cannot know whether it will commit. > > > > Of course. We need to keep a list of such that tuples until commit or > > abort. > > what about other transactions, which may have started before current one > and be still running when current one commites ? Then dead tuples should be left. Perhaps in this case we could register them in FSM or whatever for later processing. -- Tatsuo Ishii > I once proposed an extra parameter added to VACUUM FULL which determines > how much free space to leave in each page vacuumed. If there were room > the new tuple could be placed near the old one in most cases and thus > avoid lots of disk head movement when updating huge tables in one go. > > ------------ > > Hannu Krosing <hannu@tm.ee> > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
В списке pgsql-performance по дате отправления: