Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Дата
Msg-id 52D6466E.9010803@vmware.com
обсуждение исходный текст
Ответ на Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance  (Jim Nasby <jim@nasby.net>)
Ответы Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance  (Jan Kara <jack@suse.cz>)
Список pgsql-hackers
On 01/15/2014 06:01 AM, Jim Nasby wrote:
> For the sake of completeness... it's theoretically silly that Postgres
> is doing all this stuff with WAL when the filesystem is doing something
> very similar with it's journal. And an SSD drive (and next generation
> spinning rust) is doing the same thing *again* in it's own journal.
>
> If all 3 communities (or even just 2 of them!) could agree on the
> necessary interface a tremendous amount of this duplicated technology
> could be eliminated.
>
> That said, I rather doubt the Postgres community would go this route,
> not so much because of the presumably massive changes needed, but more
> because our community is not a fan of restricting our users to things
> like "Thou shalt use a journaled FS or risk all thy data!"

The WAL is also used for continuous archiving and replication, not just 
crash recovery. We could skip full-page-writes, though, if we knew that 
the underlying filesystem/storage is guaranteeing that a write() is atomic.

It might be useful for PostgreSQL somehow tell the filesystem that we're 
taking care of WAL-logging, so that the filesystem doesn't need to.

- Heikki



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: nested hstore patch - FailedAssertion("!(value->array.nelems == 1)