Re: Real time query analyzer - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: Real time query analyzer
Date
Msg-id 20061018225611.GI56874@nasby.net
Whole thread Raw
In response to Re: Real time query analyzer  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: Real time query analyzer  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-general
On Wed, Oct 18, 2006 at 05:42:22PM -0500, Ron Johnson wrote:
> > In any case, you'll be much, much happier if you do this project on at
> > least 8.1.x, as 7.4 is pretty long in the tooth. Due to Red Hat's
> > support requirements it will probably remain supported for a few more
> > years by Tom/the community, but you might start having issues getting
> > commercial support.
>
> We'll be using RHES4, I guess, so if it uses 7.4, then I'll have to
> convince the SysAdmin to install 8.1 or 8.2.

Typical reports are that 8.1 is 2x faster than 7.4, so it's probably
well worth it to do so. If support from Red Hat becomes an issue,
there's other options available.

> > Are you planning on backing up straight to tape?
>
> The data CSV files will already be on OpenVMS tapes, so it's not a
> *primary* concern.
>
> *If* it gets purchased, and *if* it is put on the gigabit LAN, then
> I'd try for some sort of remote backup.
>
> Since the data will be relatively static (only loaded monthly, and
> no updates or deletes) and in by-quarter tables, I'm thinking that
> it would be adequate to "pg_dump -t" on the /current/ tables, "tar
> cj", ftp the tarball it to a machine with a tape drive.

If that's OK for backups then you could use the same technique to
upgrade (assuming upgrade-in-place isn't available).
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

pgsql-general by date:

Previous
From: "Ale Raza"
Date:
Subject: Link error: LNK2019: unresolved external symbol _pg_detoast_datum
Next
From: Ron Johnson
Date:
Subject: Re: Real time query analyzer