Re: 15,000 tables

From: Ron <rjpeace(at)earthlink(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-performance(at)postgresql(dot)org
Subject: Re: 15,000 tables
Date: 2005-12-02 08:15:00
Message-ID: 6.2.5.6.0.20051202030859.0360c1a8@earthlink.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda pgsql-performance

Agreed, and I apologize for the imprecision of my post below.

I should have written:
"Best practice seems to be to use a journaling fs and log metadata
only and put it on separate dedicated spindles."

I've seen enough HD failures that I tend to be paranoid and log the
metadata of fs dedicated to WAL as well, but that may very well be overkill.

Ron

At 01:57 PM 12/1/2005, Tom Lane wrote:
>Ron <rjpeace(at)earthlink(dot)net> writes:
> > Agreed. Also the odds of fs corruption or data loss are higher in a
> > non journaling fs. Best practice seems to be to use a journaling fs
> > but to put the fs log on dedicated spindles separate from the actual
> > fs or pg_xlog.
>
>I think we've determined that best practice is to journal metadata only
>(not file contents) on PG data filesystems. PG does expect the filesystem
>to remember where the files are, so you need metadata protection, but
>journalling file content updates is redundant with PG's own WAL logging.
>
>On a filesystem dedicated to WAL, you probably do not need any
>filesystem journalling at all --- we manage the WAL files in a way
>that avoids changing metadata for a WAL file that's in active use.
>A conservative approach would be to journal metadata here too, though.
>
> regards, tom lane

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Mario Soto Cordones - Venezuela 2005-12-02 11:28:50 Re: Como verificar los Querys que se estan ejecutando en Pg
Previous Message ramirex 2005-12-02 03:20:10 Re: alter de una tabla

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Stone 2005-12-02 13:02:16 Re: 15,000 tables
Previous Message Luke Lonergan 2005-12-02 08:06:43 Re: Database restore speed