Re: Filesystems WAS: Perfomance Tuning
От | Richard Welty |
---|---|
Тема | Re: Filesystems WAS: Perfomance Tuning |
Дата | |
Msg-id | E19mfnc-0007W1-8n@skipper.averillpark.net обсуждение исходный текст |
Ответ на | Re: Filesystems WAS: Perfomance Tuning (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Filesystems WAS: Perfomance Tuning
Re: Filesystems WAS: Perfomance Tuning |
Список | pgsql-performance |
On Tue, 12 Aug 2003 13:09:42 -0700 Josh Berkus <josh@agliodbs.com> wrote: > This idea has been discussed numerous times on the HACKERS list, and is > a > (pretty much) closed issue. While Oracle and SQL Server use their own > filesystems, PostgreSQL will not because: ... > 2) The filesystem projects out there are (mostly) well-staffed and are > constantly advancing using specialized technology and theory. There's > no way > that the PostgreSQL team can do a better job in our "spare time". i consider this a fair answer, but i have a slightly different question to ask, inspired by my discussions with a good friend who is a top notch Informix DBA. there are advantages to being able to split the database across a slew of disk drives. if we accept the notion of using the native OS filesystem on each, it would seem that being able to direct various tables and indices to specific drives might be a valuble capability. i know that i could go into /var/lib/pgsql/data/base and fan the contents out, but this is unweildy and impractical. has any consideration been given to providing a way to manage such a deployment? or is it the judgement of the hackers community that a monsterous raid-10 array offers comparable performance? i forget how large the data store on my friend's current project is, but i'll check. knowing the size and transaction rate he's dealing with might put a finer point on this discussion. richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
В списке pgsql-performance по дате отправления: