Re: Anything to be gained from a 'Postgres Filesystem'?

Поиск
Список
Период
Сортировка
От Markus Schaber
Тема Re: Anything to be gained from a 'Postgres Filesystem'?
Дата
Msg-id 20041104120047.62810c8f@kingfisher.intern.logi-track.com
обсуждение исходный текст
Ответ на Re: Anything to be gained from a 'Postgres Filesystem'?  ("Leeuw van der, Tim" <tim.leeuwvander@nl.unisys.com>)
Ответы Re: Anything to be gained from a 'Postgres Filesystem'?  (Pierre-Frédéric Caillaud<lists@boutiquenumerique.com>)
Список pgsql-performance
Hi, Leeuw,

On Thu, 21 Oct 2004 12:44:10 +0200
"Leeuw van der, Tim" <tim.leeuwvander@nl.unisys.com> wrote:

> (I'm not sure if it's a good idea to create a PG-specific FS in your
> OS of choice, but it's certainly gonna be easier than getting FS code
> inside of PG)

I don't think PG really needs a specific FS. I rather think that PG
could profit from some functionality that's missing in traditional UN*X
file systems.

posix_fadvise(2) may be a candidate. Read/Write bareers another pone, as
well asn syncing a bunch of data in different files with a single call
(so that the OS can determine the best write order). I can also imagine
some interaction with the FS journalling system (to avoid duplicate
efforts).

We should create a list of those needs, and then communicate those to
the kernel/fs developers. Then we (as well as other apps) can make use
of those features where they are available, and use the old way
everywhere else.

Maybe Reiser4 is a step into the right way, and maybe even a postgres
plugin for Reiser4 will be worth the effort. Maybe XFS/JFS etc. already
have such capabilities. Maybe that's completely wrong.

cheers,
Markus

--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com

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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: index not used if using IN or OR
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Restricting Postgres