On Tue, Mar 9, 2010 at 9:56 AM, Scott Marlowe wrote:
> On Tue, Mar 9, 2010 at 6:47 AM, Scot Kreienkamp
> wrote:
> > Wish I could Tom. I need a non-production, read-write copy of the
> > database that is updated every 1-2 hours from production. I don't set
> > this requirement, the business does.
ISTM that 9.0's read-only standby feature may be of use to you. I know
it doesn't help you *today* but have you looked at it yet?
[Scot Kreienkamp]
I had considered it and it will make my life easier for my reporting
server, but unfortunately in this case I need a read-write copy.
On Tue, Mar 9, 2010 at 6:47 AM, Scot Kreienkamp wrote:
> Wish I could Tom. I need a non-production, read-write copy of the
> database that is updated every 1-2 hours from production. I don't set
> this requirement, the business does. I just have to do it if it's
> technically possible.
>
> I foun
Would the stats come across in WAL log shipping to a physically separate
server? My understanding is that they won't.
Thanks,
Scot Kreienkamp
skre...@la-z-boy.com
-Original Message-
From: gsst...@gmail.com [mailto:gsst...@gmail.com] On Behalf Of Greg Stark
Sent: Tuesday, March 09, 201
I'm gonna take a scientific wild-assed guess that the real issue here
is caching, or more specifically, lack thereof when you first start up
your copy of the db.
[Scot Kreienkamp]
That is definitely one of the problems. No way to help that that I'm
aware of.
--
Sent via pgsql-general mailing
On Tue, Mar 9, 2010 at 1:47 PM, Scot Kreienkamp wrote:
> I found a way to do it very easily using LVM snapshots and WAL log
> shipping, but the net effect is I'm bringing a new LVM snapshot copy of
> the database out of recovery every 1-2 hours. That means I'd have to
> spend 15 minutes, or one-q
...@la-z-boy.com
>
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Monday, March 08, 2010 10:32 PM
> To: Scot Kreienkamp
> Cc: Scott Mead; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] autovacuum question
>
> "Scot Kreienkamp&q
ISTM that 9.0's read-only standby feature may be of use to you. I know
it doesn't help you *today* but have you looked at it yet?
Okay, so the RO database won't work. How much data are we talking?
How much growth do you see between snapshots?
The initial database size is 31 gigs.
Scot Kreienkamp
Cc: Scott Mead; pgsql-general@postgresql.org
Subject: Re: [GENERAL] autovacuum question
"Scot Kreienkamp" writes:
>> Why not just add an 'analyze' as the last step of the restore job?
> Due to the amount of time it takes. The disks are slow enough to m
On Tue, Mar 9, 2010 at 10:01 AM, Scott Mead wrote:
>
> On Tue, Mar 9, 2010 at 9:56 AM, Scott Marlowe wrote:
>
>> On Tue, Mar 9, 2010 at 6:47 AM, Scot Kreienkamp
>> wrote:
>> > Wish I could Tom. I need a non-production, read-write copy of the
>> > database that is updated every 1-2 hours from pro
"Scot Kreienkamp" writes:
>> Why not just add an 'analyze' as the last step of the restore job?
> Due to the amount of time it takes. The disks are slow enough to make a
> database-wide analyze painful since I would have to repeat it every 1-2
> hours, IE every reload time.
You claimed that b
On Mon, Mar 8, 2010 at 5:13 PM, Scot Kreienkamp
wrote:
Hi everyone,
I have a database that is constantly getting reloaded several times per
day from production backups and is used for reporting purposes. The
problem I'm having with it is that the database seems to be much slower
than the oth
On Mon, Mar 8, 2010 at 5:13 PM, Scot Kreienkamp wrote:
> Hi everyone,
>
> I have a database that is constantly getting reloaded several times per
> day from production backups and is used for reporting purposes. The
> problem I'm having with it is that the database seems to be much slower
> than
Hi everyone,
I have a database that is constantly getting reloaded several times per
day from production backups and is used for reporting purposes. The
problem I'm having with it is that the database seems to be much slower
than the others I have that are more static. I suspect that is due to
t
14 matches
Mail list logo
