Re: Design proposal: fsync absorb linear slider

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Design proposal: fsync absorb linear slider
Дата
Msg-id 52153FC6.4030004@nasby.net
обсуждение исходный текст
Ответ на Re: Design proposal: fsync absorb linear slider  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 7/26/13 7:32 AM, Tom Lane wrote:
> Greg Smith <greg@2ndQuadrant.com> writes:
>> On 7/26/13 5:59 AM, Hannu Krosing wrote:
>>> Well, SSD disks do it in the way proposed by didier (AFAIK), by putting
>>> "random"
>>> fs pages on one large disk page and having an extra index layer for
>>> resolving
>>> random-to-sequential ordering.
>
>> If your solution to avoiding random writes now is to do sequential ones
>> into a buffer, you'll pay for it by having more expensive random reads
>> later.
>
> What I'd point out is that that is exactly what WAL does for us, ie
> convert a bunch of random writes into sequential writes.  But sooner or
> later you have to put the data where it belongs.

FWIW, at RICon East there was someone from Seagate that gave a presentation. One of his points is that even spinning
rustis moving to the point where the drive itself has to do some kind of write log. He notes that modern filesystems do
thesame thing, and the overlap is probably stupid (I pointed out that the most degenerate case is the logging database
onthe logging filesystem on the logging drive...)
 

It'd be interesting for Postgres to work with drive manufacturers to study ways to get rid of the extra layers of
stupid...
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: HeapTupleSatisfiesDirty fails to test HEAP_XMAX_IS_LOCKED_ONLY for TransactionIdIsInProgress(...)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: docbook-xsl version for release builds