Re: TOAST performance (was Re: [GENERAL] Delete Performance)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: TOAST performance (was Re: [GENERAL] Delete Performance)
Дата
Msg-id 200111170244.fAH2iNx18520@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: TOAST performance (was Re: [GENERAL] Delete Performance)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: TOAST performance (was Re: [GENERAL] Delete Performance)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Could we add code to detect a partial write when we recover from one
> > using WAL so we can know if these partial writes are ever
> > happening?
> 
> What's your point?  It clearly *can* happen during power-failure
> scenarios.  All the monitoring in the world won't disprove that.

My point is uh, um, eh, I think it is a very important point that I
should make ... um.  :-)

Seriously, how do OS's handle partial page write, especially to
directories?

Another item I was considering is that INSERT and UPDATE, because they
append to the tables, don't really cause lots of pre-page writes, while
DELETE could affect all page in a table and would require pre-page
writes on all of them.  

However, deletes are only marking the XID status of the rows. 
Unfortunately I can't think of a way of recording those new XID's in WAL
and preventing a possible failure while the XID's are written to the
page.  Can someone help me here?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: TOAST performance (was Re: [GENERAL] Delete Performance)
Следующее
От: Justin Clift
Дата:
Сообщение: Re: Super Optimizing Postgres