Re: Design proposal: fsync absorb linear slider

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Design proposal: fsync absorb linear slider
Дата
Msg-id 51F25727.7040404@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Design proposal: fsync absorb linear slider  (Hannu Krosing <hannu@2ndQuadrant.com>)
Ответы Re: Design proposal: fsync absorb linear slider  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.  In the SSD write buffer case, that works only because those 
random reads are very cheap.  Do the same thing on a regular drive, and 
you'll be paying a painful penalty *every* time you read in return for 
saving work *once* when you write.  That only makes sense when your 
workload is near write-only.

It's possible to improve on this situation by having some sort of 
background process that goes back and cleans up the random data, 
converting it back into sequentially ordered writes again.  SSD 
controllers also have firmware that does this sort of work, and Postgres 
might do it as part of vacuum cleanup.  But note that such work faces 
exactly the same problems as writing the data out in the first place.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



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

Предыдущее
От: marco atzeri
Дата:
Сообщение: Re: install libpq.dll in bin directory on Windows / Cygwin
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])