* Simon Riggs (simon@2ndquadrant.com) wrote:
> On Thu, 2005-12-22 at 21:18 +0100, Martijn van Oosterhout wrote:
> > Considering "WAL bypass" is code for "breaks PITR"
>
> No it isn't. All of the WAL bypass logic does *not* operate when PITR is
> active. The WAL bypass logic is aimed at Data Warehouses, which
> typically never operate in PITR mode for performance reasons, however
> the choice is yours.
Eh? PITR mode is bad for performance? Maybe I missed something but I
wouldn't have thought PITR would degrade regular performance all that
badly. So long as it doesn't take 15 minutes or some such to move the
WAL to somewhere else (and I'm not sure that'd even slow things down..).
For a Data Warehouse, have you got a better way of doing backups such
that you don't lose at minimum most of a day's work? I'm not exactly a
big fan do doing a pg_dump every night either given that the database is
360GB. Much nicer to take a weekly dump of the database and then do
PITR for a week or two before taking another dump of the db.
I like the idea of making COPY go faster, but please don't break my
backup system while you're at it. I'm honestly kind of nervous about
what you mean by checking it PITR is active- how is that done, exactly?
Check if you have a script set to rotate the logs elsewhere? Or is it
checking if you're in the taking-a-full-database-backup stage? Or what?
What's the performance decrease when using PITR, and what's it from? Is
it just that COPY isn't as fast? Honestly, I could live with COPY being
not as fast as it could be if my backups work. :)
Sorry for sounding concerned but, well, backups are very important and
so is performance and I'm afraid either I've not read all the
documentation about the issues being discussed here or there isn't
enough out there to make sense of it all yet. :)
Thanks,
Stephen