Re: Real time query analyzer

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Real time query analyzer
Дата
Msg-id 20061018225611.GI56874@nasby.net
обсуждение исходный текст
Ответ на Re: Real time query analyzer  (Ron Johnson <ron.l.johnson@cox.net>)
Ответы Re: Real time query analyzer  (Ron Johnson <ron.l.johnson@cox.net>)
Список 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 по дате отправления:

Предыдущее
От: "Ale Raza"
Дата:
Сообщение: Link error: LNK2019: unresolved external symbol _pg_detoast_datum
Следующее
От: Ron Johnson
Дата:
Сообщение: Re: Real time query analyzer