Re: Backup very large databases - Mailing list pgsql-general

From Curt Sampson
Subject Re: Backup very large databases
Date
Msg-id Pine.NEB.4.43.0204211404550.6249-100000@angelic.cynic.net
Whole thread Raw
In response to Re: Backup very large databases  (Ron Snyder <snyder@roguewave.com>)
List pgsql-general
On Sat, 20 Apr 2002, Ron Snyder wrote:

> > I think the better question is.. do people who has a special
> > situation due to their DB size want to go through all of the GENERAL
> > mails.

In my case, no. I try to get through the general mail, but if I'm
short on time, it would be really nice to be able to ignore the day's
postings to general, but still know that I can find some things of
particular interest to me (i.e., stuff I really don't want to miss) on
the performance list.

> It seems to me that you are presuming that none of the GENERAL emails
> would apply to those who also have large systems, or that those who
> have large systems have nothing to learn from the GENERAL list.

No. It's a matter not of what else in general would apply, but how
does one get at least the most important stuff when one is short
of time.

> I believe that more people will be interested in both topics than will
> be interested in only one....

That doesn't really matter, I think. People interested in both
topics can easily subscribe to both lists. The real question, to
my mind, is "are there people who would find it useful to see just
performance-related stuff." Which I think is true.

Thus, I'd like to see a separate performance list.

Here's my stab at a charter:

    The pgsql-performance list is for technical discussion relating
    to the performance (speed and efficiency) of PostgreSQL. In
    particular, discussions of the performance of common or uncommon
    operations on very large databases are welcome.

    However, "why isn't this query using this index?" questions
    are strongly discouraged, unless you understand the PostgreSQL
    optimizer, are proposing changes to it, and have data to show
    that the change improves the optimizer in a wide variety of
    situations, not just your particular one.

This description could probably be made a lot better, but I think
you get the idea. The reasons for the second paragraph should be
fairly obvious to hacker types, if not less technical users of
PostgreSQL.

cjs
--
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC


pgsql-general by date:

Previous
From: "Rishabh Gupta"
Date:
Subject: postgresql query to XML result
Next
From: Curt Sampson
Date:
Subject: One particular large database application