Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Nov 16, 2009, at 8:31 PM, Tom Lane wrote: Make sure you're not in the line of fire when (not if) that version eats your data. Particularly on Windows, insisting on not upgrading that version is unbelievably, irresponsibly stupid. There are a *large* number of known bugs. I hear ya, and h

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 7:45 PM, Greg Smith wrote: > Tom Lane wrote: > > cb writes: > > > Ugh, yeah, I'd love to upgrade but the powers that get to make that > decision have no interest in upgrading. So I'm stuck on 8.0.4, > > > Make sure you're not in the line of fire when (not if) that version

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

Tom Lane wrote: cb writes: Ugh, yeah, I'd love to upgrade but the powers that get to make that decision have no interest in upgrading. So I'm stuck on 8.0.4, Make sure you're not in the line of fire when (not if) that version eats your data. Particularly on Windows, insisting on not

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

cb writes: > Ugh, yeah, I'd love to upgrade but the powers that get to make that > decision have no interest in upgrading. So I'm stuck on 8.0.4, Make sure you're not in the line of fire when (not if) that version eats your data. Particularly on Windows, insisting on not upgrading that version

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Nov 16, 2009, at 1:11 PM, Robert Schnabel wrote: I've been a Diskeeper customer for about 10 years now and consider it 'must have' software for Windows machines. So the short answer is yes, I have it running with PostgreSQL and have not had any problems. So that seems to be a definite

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Nov 16, 2009, at 1:09 PM, Robert Haas wrote: I'm not sure what the answer is to your actual question, but I'd highly recommend upgrading to 8.3 or 8.4. The performance is likely to be a lot better, and 8.0/8.1 are no longer supported on Windows. Ugh, yeah, I'd love to upgrade but the powe

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 2:04 PM, Robert Schnabel wrote: > Granted, but the point of me testing this is to say whether or not the > Diskeeper service could introduce a problem.  If the system recovers without > Diskeeper running but does not recover while Diskeeper is actively running > then we ha

Re: [PERFORM] Unexpected sequential scan on an indexed column

Thanks, Dave. Eddy On Mon, Nov 16, 2009 at 1:52 PM, Dave Crooke wrote: > With Postgres, you can transparently replace a regular select with a > function that takes the same types and returns a record iterator with the > same columns. The only change needed is the SQL used to invoke it, you won't

Re: [PERFORM] Unexpected sequential scan on an indexed column

With Postgres, you can transparently replace a regular select with a function that takes the same types and returns a record iterator with the same columns. The only change needed is the SQL used to invoke it, you won't need any logic changes in your app code (Java or whatever), e.g. *select .

Re: [PERFORM] Unexpected sequential scan on an indexed column

This is incredibly helpful, Kenneth. I didn't know about the SETOF syntax at all. This could help minimize the amount of refactoring I need to do. Thanks! Eddy On Mon, Nov 16, 2009 at 12:55 PM, Kenneth Marshall wrote: > On Mon, Nov 16, 2009 at 12:45:46PM -0800, Eddy Escardo-Raffo wrote: > > Yea

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 03:20:12PM -0500, Greg Smith wrote: > Robert Schnabel wrote: > >Nope. Forgive my ignorance but isn't that what a UPS is for anyway? > >Along with a BBU controller. > > If you have a UPS *and* a BBU controller, then things are much > better--those should have a write cach

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

Craig James escribió: > Do it more than once. This is a highly erratic test that can catch > your system at a wide variety of points, some of which cause no > problems, and some of which can be catastrophic. If you test and it > fails, you know you have a problem. If you test and it doesn't fai

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

I also have backup software running that does complete drive imaging so I should be able to do this fairly safely. Here is the plan... 1) Shut down the Diskeeper service, run a query that is write heavy and then pull the chord on the box. Wait a few minutes then plug it back in and see if i

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

Scott Marlowe wrote: On Mon, Nov 16, 2009 at 1:32 PM, Robert Schnabel wrote: Ok, so you have sufficiently sparked my curiosity as to whether Diskeeper will in any way cause Postgres to fail the power chord test.  Unfortunately I have some deadlines to meet so won't be able to test

Re: [PERFORM] Unexpected sequential scan on an indexed column

On Mon, Nov 16, 2009 at 12:45:46PM -0800, Eddy Escardo-Raffo wrote: > Yeah this kind of thing would probably work. Doing this in java with > separate queries would be easy to code but require multiple round trips. > Doing it as a stored procedure would be nicer but I'd have to think a little > more

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 1:32 PM, Karl Denninger wrote: > Dave Crooke wrote: >> My reply about server failure was shwoing what could go wrong at the >> server level assuming a first-class, properly run data center, with >> fully redundant power, including a server with dual power supplies on >> sep

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 1:32 PM, Robert Schnabel wrote: > > Ok, so you have sufficiently sparked my curiosity as to whether Diskeeper > will in any way cause Postgres to fail the power chord test.  Unfortunately > I have some deadlines to meet so won't be able to test this out until later Best ti

Re: [PERFORM] Unexpected sequential scan on an indexed column

Yeah this kind of thing would probably work. Doing this in java with separate queries would be easy to code but require multiple round trips. Doing it as a stored procedure would be nicer but I'd have to think a little more about how to refactor the java code around the query to make this happen. T

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

Dave Crooke wrote: > My reply about server failure was shwoing what could go wrong at the > server level assuming a first-class, properly run data center, with > fully redundant power, including a server with dual power supplies on > separate cords fed by separate UPS'es etc. Never had a mothe

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

Scott Marlowe wrote: On Mon, Nov 16, 2009 at 1:04 PM, Robert Schnabel wrote:  So the short answer is yes, I have it running with PostgreSQL and have not had any problems. Have you unplugged the power cord a few times in the middle of heavy write activity? ...Robert Nope.  For

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

My reply about server failure was shwoing what could go wrong at the server level assuming a first-class, properly run data center, with fully redundant power, including a server with dual power supplies on separate cords fed by separate UPS'es etc. Unfortunately, *correctly* configured A/B p

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

Greg Smith wrote: > Robert Schnabel wrote: >> Nope. Forgive my ignorance but isn't that what a UPS is for anyway? >> Along with a BBU controller. > If you have a UPS *and* a BBU controller, then things are much > better--those should have a write cache that insulates you from the > worst of the p

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

Robert Schnabel wrote: Nope. Forgive my ignorance but isn't that what a UPS is for anyway? Along with a BBU controller. If you have a UPS *and* a BBU controller, then things are much better--those should have a write cache that insulates you from the worst of the problems. But just a UPS alo

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 1:12 PM, Scott Marlowe wrote: > Power supplies / UPSes fail far more often than one might think.  And > a db that doesn't come back up afterwards is not to be placed into > production. Note that there are uses for databases that can lose everything and just initdb and be h

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 1:04 PM, Robert Schnabel wrote: > >  So the short answer is yes, I have it running with > PostgreSQL and have not had any problems. > > > Have you unplugged the power cord a few times in the middle of heavy > write activity? > > ...Robert > > Nope.  Forgive my ignorance but

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

 So the short answer is yes, I have it running with PostgreSQL and have not had any problems. Have you unplugged the power cord a few times in the middle of heavy write activity? ...Robert Nope.  Forgive my ignorance but isn't that what a UPS is for anyway?  Along with a B

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 1:11 PM, Robert Schnabel wrote: > cb wrote: >> >> I'm curious if anyone else has used Diskeeper's Automatic Mode in >>  combination with PostgreSQL to defrag and keep the drive defragged  while >> PostgreSQL is actually running. >> >> Thanks! >> >> -chris >> >> > > I've be

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

cb wrote: I'm curious if anyone else has used Diskeeper's Automatic Mode in combination with PostgreSQL to defrag and keep the drive defragged while PostgreSQL is actually running. Thanks! -chris I've been a Diskeeper customer for about 10 years now and consider it 'must have' softwa

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

On Mon, Nov 16, 2009 at 12:14 PM, cb wrote: > I've got a pair of servers running PostgreSQL 8.0.4 on Windows. We have > several tables that add and delete massive amounts of data in a single day > and are increasingly having a problem with drive fragmentation and it > appears to be giving us a dec

[PERFORM] Is Diskeeper Automatic Mode safe?

I've got a pair of servers running PostgreSQL 8.0.4 on Windows. We have several tables that add and delete massive amounts of data in a single day and are increasingly having a problem with drive fragmentation and it appears to be giving us a decent performance hit. This is external fragmen

Re: [PERFORM] Unexpected sequential scan on an indexed column

Hi Eddy Perhaps a slightly naive suggestion have you considered converting the query to a small stored procedure ('function' in Postgres speak)? You can pull the location values, and then iterate over a query like this: select userid from users where location=:x which is more-or-less guaran

Re: [PERFORM] Manual vacs 5x faster than autovacs?

Quoting Scott Marlowe : On Mon, Nov 16, 2009 at 9:13 AM, Wayne Beaver wrote: Quoting Scott Marlowe : On Thu, Nov 12, 2009 at 9:58 AM, Wayne Beaver wrote: Quoting Scott Marlowe : On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver wrote: I'd seen autovacs running for hours and had mis-attribu

Re: [PERFORM] Manual vacs 5x faster than autovacs?

On Mon, Nov 16, 2009 at 9:13 AM, Wayne Beaver wrote: >> Quoting Scott Marlowe : >> >>> On Thu, Nov 12, 2009 at 9:58 AM, Wayne Beaver wrote: Quoting Scott Marlowe : >> On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver >> wrote: >> I'd seen autovacs running for hours and had

Re: [PERFORM] Manual vacs 5x faster than autovacs?

Quoting Scott Marlowe : On Thu, Nov 12, 2009 at 9:58 AM, Wayne Beaver wrote: Quoting Scott Marlowe : On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver wrote: I'd seen autovacs running for hours and had mis-attributed this to growing query times on those tables - my thought was that "shrinkin

Re: [PERFORM] Unexpected sequential scan on an indexed column

OK, I think that after reading this doc (which I hadn't encountered before) about the optimizer, something clicked in my brain and I think I can answer my own question. I was basically thinking from my own perspective rather than from the que

Re: [PERFORM] limiting performance impact of wal archiving.

On Thu, Nov 12, 2009 at 3:21 PM, Laurent Laborde wrote: > Hi ! > > Here is my plan : > - rebuilding a spare with ext3, raid10, without lvm > - switch the slony master to this new node. Done 3 days ago : Problem solved ! It totally worked. \o/ -- ker2x sysadmin & DBA @ http://www.over-blog.com/