]>
Cc: "Trond Eivind Glomsrød" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 1:24 PM
Subject: Re: [HACKERS] Re: New Linux xfs/reiser file systems
> > I'm concearned about this because we are going to switch our
> > fist server to a J
Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > When compared to the earlier ones (including XFS), you'll note that ReiserFS
> > performance is rather poor in some of the tests - it takes 37 vs. 13
> > seconds for 8192 inserts, when the inserts are different transactions.
>
> That is all the
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
> [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
>
> > "Ken Hirsch" <[EMAIL PROTECTED]> writes:
> >
> > > I don't have a machine with XFS installed and it will be at least a week
> > > before I could get around to a build. Any volunteers?
>
[EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
> "Ken Hirsch" <[EMAIL PROTECTED]> writes:
>
> > I don't have a machine with XFS installed and it will be at least a week
> > before I could get around to a build. Any volunteers?
>
> I think I could do that... any useful benchmarks to run?
In
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Even the IMHO hardest to solve problem
> - RENAME - can
> probably be done in a transaction-safe manner by doing a
> link(oid.) in the
> beginning and selective unlink(oid.) at commit time.
Nope. Consider
begin;
rename a to b;
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> OK we can do that with symlinks, but is there a PGSQL Recommended or
> Standard way to do it, so as to reduce administrative errors, and at least
> help improve consistency with multiadmin pgsql installations?
Not yet. There should be support for this.
> I think the XFS and Reiserfs folks will be happy to look at the
performance
> problem, but it would be very helpful for them to have a prepackaged
> benchmark (or two or three) to use. We should set up an FTP area to
share
> them. Joe, can you contribute yours? Does anybody else have anythi
Joe Conway <[EMAIL PROTECTED]> wrote:
>
> I've done some testing to see how Reiserfs performs
> vs ext2, and also various for various values of wal_sync_method while on a
> reiserfs partition. The attached graph shows the results. The y axis is
> transactions per second and the x axis is the trans
> > There have been multiple reports of poor PostgreSQL performance on
> > Reiser and xfs. I don't have numbers, though. Frankly, I think we need
> > xfs and reiser experts involved to figure out our options here.
>
> I've done some testing to see how Reiserfs performs
> vs ext2, and also vario
"Ken Hirsch" <[EMAIL PROTECTED]> writes:
> I don't have a machine with XFS installed and it will be at least a week
> before I could get around to a build. Any volunteers?
I think I could do that... any useful benchmarks to run?
--
Trond Eivind Glomsrød
Red Hat, Inc.
> On Fri, May 04, 2001 at 08:02:17AM -0400, mlw wrote:
> > The way I understand it is that ReiserFS does not attempt to separate files at
> > the block level. Multiple files can live in the same disk block. This is cool
> > if you have many small files, but the extra overhead for large files such
[ Charset ISO-8859-1 unsupported, converting... ]
> > Sure, we can do that now. What do we do when these are the default file
> > systems for Linux? We can tell them to create other types of file
>
> What is a 'default file system' ? I know that untill now, everybody is using
> ext2. But that'
[ Charset ISO-8859-1 unsupported, converting... ]
> Before we get too involved in speculating, shouldn't we actually measure the
> performance of 7.1 on XFS and Reiserfs? Since it's easy to disable fsync,
> we can test whether that's the problem. I don't think that logging file
> systems must in
> Sure, we can do that now. What do we do when these are the default file
> systems for Linux? We can tell them to create other types of file
What is a 'default file system' ? I know that untill now, everybody is using
ext2. But that's only because there hasn't been anything comparable. Now we
> "Bruce" == Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Well, arguably if you're setting up a database server then a
>> reasonable DBA should think about such things...
Bruce> Yes, but people have trouble installing PostgreSQL. I
Bruce> can't imagine walking them through a
On Fri, May 04, 2001 at 08:02:17AM -0400, mlw wrote:
> The way I understand it is that ReiserFS does not attempt to separate files at
> the block level. Multiple files can live in the same disk block. This is cool
> if you have many small files, but the extra overhead for large files such as
> tho
mlw <[EMAIL PROTECTED]> writes:
> I have looked at Reiser, and I don't think it is a file system suited for very
> large files, or applications such as postgres.
What's the problem with big files? ReiserFS v2 doesn't seem to support
it, while v3 seems just fine (of the ondisk format)
That said,
On Thu, May 03, 2001 at 11:41:24AM -0400, Bruce Momjian wrote:
> ext2 has serious problems with corrupt file systems after a crash, so I
> understand the need to move to another file system type. I have been
> waitin for Linux to get a more modern file system. Unfortunately, the
> new ones seem t
>
> > Just put a note in the installation docs that the place where the
>database
> > is initialised to should be on a non-Reiser, non-XFS mount...
>
>Sure, we can do that now.
I still think this is not necessarily the right approach either. One
major purpose of using a journaling fs is for fast
Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 4 May 2001 9:42 AM
> To: Christopher Kings-Lynne
> Cc: mlw; Hackers List
> Subject: Re: [HACKERS] Re: New Linux xfs/reiser file systems
>
>
> > Just put a note in the installation docs that the
> Just put a note in the installation docs that the place where the database
> is initialised to should be on a non-Reiser, non-XFS mount...
Sure, we can do that now. What do we do when these are the default file
systems for Linux? We can tell them to create other types of file
systems, but tha
t: Re: [HACKERS] Re: New Linux xfs/reiser file systems
> Just put a note in the installation docs that the place where the database
> is initialised to should be on a non-Reiser, non-XFS mount...
Sure, we can do that now. What do we do when these are the default file
systems for Linux?
Just put a note in the installation docs that the place where the database
is initialised to should be on a non-Reiser, non-XFS mount...
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of mlw
Sent: Thursday, 3 May 2001 8:09 PM
To: Bruce Momjian; Hacke
On Thu, 3 May 2001, mlw wrote:
> This behavior raises the question about file system usage in Postgres. Many
> databases, such as Oracle, create table space files and operate directly on the
> raw blocks, bypassing the file system altogether.
>
> On one hand, Postgres is easy to use and maintain
> > This behavior raises the question about file system usage in Postgres. Many
> > databases, such as Oracle, create table space files and operate directly on the
> > raw blocks, bypassing the file system altogether.
>
> OK, we have considered this, but frankly, the new, modern file systems
> lik
> > kernel to do it for us. Reimplementing a filesystem doesn't strike me
> > as a profitable use of our time.)
> Ditto. The database is complicated enough.
Maybe some kind of recommendation would be a good thing. That is, if the
PostgreSQL community has enough knowledge.
A section in the doc
> Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> > From some stracing of 7.1, the most common syscall issued by
> > postgres is an lseek() to the end of the file, presumably to
> > find its length, which seems to happen up to about a dozen
> > times per (pgbench) transaction.
>
> > Tablespaces wo
Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> From some stracing of 7.1, the most common syscall issued by
> postgres is an lseek() to the end of the file, presumably to
> find its length, which seems to happen up to about a dozen
> times per (pgbench) transaction.
> Tablespaces would solve this
On Thu, 3 May 2001, mlw wrote:
> I would bet it is a huge amount of work to use a "table space" system
> and no one wants that.
>From some stracing of 7.1, the most common syscall issued by
postgres is an lseek() to the end of the file, presumably to
find its length, which seems to happen up to
29 matches
Mail list logo
