Re: [GENERAL] setting for maximum acceptable plan cost?

2007-11-02 Thread Jeffrey W. Baker
On Fri, 2007-11-02 at 14:45 -0700, Joshua D. Drake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, 02 Nov 2007 13:49:27 -0700 > "Jeffrey W. Baker" <[EMAIL PROTECTED]> wrote: > > > Nested Loop Left Join (cost=13920.16..225757555

[GENERAL] setting for maximum acceptable plan cost?

2007-11-02 Thread Jeffrey W. Baker
I was thinking that it might be nice to be able to tell postgres to refuse to execute any plan with an estimated cost above some threshold. For example, earlier today I produced this extremely bogus execution plan with the following top line: Nested Loop Left Join (cost=13920.16..2257575559347.46

[GENERAL] Baffling sequential scan plan when index scan would be best

2005-04-20 Thread Jeffrey W. Baker
I always thought I would not be the kind of person who writes to this list asking why the planner is using a sequential scan. I always looked upon such people as newcomers who would eventually learn the mysterious wonders of the Pg query execution planner. But really, this plan is bizarre! Why

Re: [GENERAL] disk performance benchmarks

2004-09-15 Thread Jeffrey W. Baker
On Wed, 2004-09-15 at 02:39, Michael Paesold wrote: > Jeffrey W. Baker wrote: > > > Current issue: > > > > A dual 64-bit Opteron 244 machine with 8GB main memory, two 4-disk RAID5 > > arrays (one for database, one for xlogs). PG's config is extremely > >

Re: [GENERAL] disk performance benchmarks

2004-09-14 Thread Jeffrey W. Baker
On Tue, 2004-09-14 at 14:45, Jim C. Nasby wrote: > On Tue, Sep 14, 2004 at 11:11:38AM -0700, Jeffrey W. Baker wrote: > > procs ---memory-- ---swap-- -io --system-- cpu > > r b swpd free buff cache si sobibo incs us sy

Re: [GENERAL] disk performance benchmarks

2004-09-14 Thread Jeffrey W. Baker
On Tue, 2004-09-14 at 10:28, Vivek Khera wrote: > > "SW" == Shane Wright writes: > > SW> But, we have now taken the plunge and I'm in a position to do some > SW> benchmarking to actually get some data. Basically I was wondering if > SW> anyone else had any particular recommendations (or requ

Re: [GENERAL] pg_xlog becomes extremely large during CREATE INDEX

2004-05-16 Thread Jeffrey W. Baker
On Fri, 2004-05-14 at 20:55, Tom Lane wrote: > Vivek Khera <[EMAIL PROTECTED]> writes: > > "TL" == Tom Lane <[EMAIL PROTECTED]> writes: > > TL> ... On looking at the code I see that it doesn't make any > > TL> attempt to prune future log segments after a decrease in > > TL> checkpoint_segments, so

Re: [GENERAL] pg_xlog becomes extremely large during CREATE INDEX

2004-05-13 Thread Jeffrey W. Baker
On Thu, 2004-05-13 at 09:28, Tom Lane wrote: > "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes: > > Sorry, my last mail got cut off. The server aborted because it couldn't > > write the xlog. Looks like I omitted this from my last mail: > > Selective q

Re: [GENERAL] pg_xlog becomes extremely large during CREATE INDEX

2004-05-13 Thread Jeffrey W. Baker
On Thu, 2004-05-13 at 06:10, Tom Lane wrote: > "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes: > > Oh sure, it's bleating. Apparently my computer is too fast: > > I don't think the checkpoint process is completing. > > > May 12 16:37:08 mistra

[GENERAL] PostgreSQL on XFS experiences?

2004-02-26 Thread Jeffrey W. Baker
Dear list, We are using PostgreSQL with the database and xlogs on (separate) XFS volumes under Linux 2.4.25. We are simply curious to hear your experiences with this combination, if you are using it. In only two days of heavy activity, we've already been able to corrupt one database. We've also

Re: [GENERAL] VACUUM, 24/7 availability and 7.2

2001-10-10 Thread Jeffrey W. Baker
On Wed, 10 Oct 2001 [EMAIL PROTECTED] wrote: > Just to keep things in perspective, how large are your current databases, and > what do you or the company consider to be a signficant length of time? Right > now I have a development database with just a few thousand records of test data, > and v