Re: [PERFORM] ways to force index use?

2003-10-14 Thread Seth Ladd
On Monday, Oct 13, 2003, at 21:24 Pacific/Honolulu, mila wrote: Seth, My system: RH9, PG 7.3.4, IDE, 1 gig RAM, celeron 1.7 ... Size of table: 16212 rows Params: shared_buffers = 128, effective_cache_size = 8192 Just in case, the "shared_buffers" value looks a bit far too small for your system. I

Re: [PERFORM] [SQL] sql performance and cache

2003-10-14 Thread Tom Lane
"Chris Faulkner" <[EMAIL PROTECTED]> writes: > I am seeing this message in my logs. > "bt_fixroot: not valid old root page" That's not good. I'd suggest reindexing that index. regards, tom lane ---(end of broadcast)--- TIP

[PERFORM] Large Text Search Help

2003-10-14 Thread psql-mail
Hi, I am trying to design a large text search database. It will have upwards of 6 million documents, along with meta data on each. I am currently looking at tsearch2 to provide fast text searching and also playing around with different hardware configurations. 1. With tsearch2 I get very good

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

2003-10-14 Thread Ivan Voras
> Date: Sun, 12 Oct 2003 13:30:45 -0700 > From: Josh Berkus <[EMAIL PROTECTED]> > To: Nick Barr <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: go for a script! / ex: PostgreSQL vs. MySQL > Message-ID: <[EMAIL PROTECTED]> > >> This would be parameters such as the block size and a f

Re: [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Kenneth Marshall
Jeff, My first concern with the -fast option is that it makes an executable that is specific for the platform on which the compilation is run unless other flags are given. My second concern is the effect it has on IEEE floating point behavior w.r.t. rounding, error handling, And my third conc

Re: [PERFORM] One or more processor ?

2003-10-14 Thread Relaxin
> Do you know of any RDBMS that actually will execute a single query on > multiple processors? SQL Server does in a sense. It can split a query onto multiple threads (which could possible use multiple processors) and then brings the results from the threads into one and then sends the results to

Re: [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Kenneth Marshall
I would use a simple -xO2 or -xO3 instead as the default with an -fsimple=2. --Ken -x02 -xbuiltin=%all On Thu, Oct 09, 2003 at 01:04:23PM -0400, Jeff wrote: > On Thu, 9 Oct 2003, Kenneth Marshall wrote: > > > Jeff, > > > > My first concern with the -fast option is that it makes an executable > >

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

2003-10-14 Thread Josh Berkus
Ivan, > There was some talk, either on this list or freebsd-performance about > setting the default block size for PostgreSQL running on FreeBSD to be 16k > because of performance reasons. That is: *default* for the port, user is > not asked. So an automagical method to scale non-default block siz

Re: [PERFORM] Large Text Search Help

2003-10-14 Thread Josh Berkus
Mat, > 1. With tsearch2 I get very good query times up until I insert more > records. For example with 100,000 records tsearch2 returns in around 6 > seconds, with 200,000 records tsearch2 returns in just under a minute. > Is this due to the indices fitting entirely in memory with 100,000 > record

Re: [PERFORM] further testing on IDE drives

2003-10-14 Thread Tom Lane
"scott.marlowe" <[EMAIL PROTECTED]> writes: > open_sync was WAY faster at this than the other two methods. Do you not have open_datasync? That's the preferred method if available. regards, tom lane ---(end of broadcast)---

Re: [PERFORM] further testing on IDE drives

2003-10-14 Thread scott.marlowe
On Tue, 14 Oct 2003, Tom Lane wrote: > "scott.marlowe" <[EMAIL PROTECTED]> writes: > > open_sync was WAY faster at this than the other two methods. > > Do you not have open_datasync? That's the preferred method if > available. Nope, when I try to start postgresql with it set to that, I get this

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

2003-10-14 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > Unless there's a way to find it in the compiled source? See pg_controldata. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend

[PERFORM] free space map usage

2003-10-14 Thread Jeremy M. Guthrie
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any way to determine how much of the free space map is currently in use?(ie. where and what it is tracking?) I vacuum on a regular basis but I never hold in terms of disk space usage. I jacked up the free space map pages but this doesn't

Re: [PERFORM] go for a script! / ex: PostgreSQL vs. MySQL

2003-10-14 Thread Sean Chittenden
> >> This would be parameters such as the block size and a few > >> other compile time parameters. If we can get to some of these > >> read-only parameters than that would make this step easier, > >> certainly for the new recruits amongst us. > > > > Actually, from my perspective, we shouldn't

Re: [PERFORM] free space map usage

2003-10-14 Thread Tom Lane
"Jeremy M. Guthrie" <[EMAIL PROTECTED]> writes: > Is there any way to determine how much of the free space map is currently i= > n=20 > use?(ie. where and what it is tracking?) I vacuum on a regular basis but I= > =20 > never hold in terms of disk space usage. Not in 7.3 AFAIR. In 7.4 a full-dat

Re: [PERFORM] Any issues with my tuning...

2003-10-14 Thread Neil Conway
On Mon, 2003-10-13 at 15:43, David Griffiths wrote: > Here are part of the contents of my sysctl.conf file (note that I've > played with values as low as 60 with no difference) > kernel.shmmax=14 > kernel.shmall=14 This is only a system-wide limit -- it either allows the share

Re: [SQL] [PERFORM] sql performance and cache

2003-10-14 Thread scott.marlowe
On Tue, 14 Oct 2003, Wei Weng wrote: > On Sat, 11 Oct 2003, Christopher Kings-Lynne wrote: > > > > > > I have two very similar queries which I need to execute. They both have > > > exactly the same from / where conditions. When I execute the first, it takes > > > about 16 seconds. The second is

Re: [PERFORM] sql performance and cache

2003-10-14 Thread Rod Taylor
> > Perhaps you are confusing it with the MySQL query cache? > Is there plan on developing one (query cache)? For the most part, prepared queries and cursors give you a greater advantage due to their versatility -- both of which we do have. In the cases where an actual cache is useful, the clien

Re: [SQL] [PERFORM] sql performance and cache

2003-10-14 Thread Wei Weng
On Sat, 11 Oct 2003, Christopher Kings-Lynne wrote: > > > I have two very similar queries which I need to execute. They both have > > exactly the same from / where conditions. When I execute the first, it takes > > about 16 seconds. The second is executed almost immediately after, it takes > > 13

Re: [PERFORM] backup/restore - another area.

2003-10-14 Thread markw
Jeff, I'm curious to what kind of testing you've done with LVM. I'm not currently trying any backup/restore stuff, but I'm running our DBT-2 workload using LVM. I've started collecting vmstat, iostat, and readprofile data, initially running disktest to gauge the performance. For anyone curious,

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Peter Eisentraut
Marko Karppinen writes: > GCC sets __FAST_MATH__ even if you counter a -ffast-math with the > negating flags above. This means that it is not currently possible to > use the -fast flag when compiling PostgreSQL at all. Instead, you have > to go through all the flags Apple is setting and only pass

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Marko Karppinen
On 8.10.2003, at 21:31, Bruce Momjian wrote: Well, this is really embarassing. I can't imagine why we would not set at least -O on all platforms. Looking at the template files, I see these have no optimization set: darwin Regarding Darwin optimizations, Apple has introduced a "-f

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Peter Eisentraut
Bruce Momjian writes: > Well, this is really embarassing. I can't imagine why we would not set > at least -O on all platforms. Looking at the template files, I see > these have no optimization set: > freebsd (non-alpha) I'm wondering what that had in mind: http://developer.postgresql.or

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Tom Lane
Marko Karppinen <[EMAIL PROTECTED]> writes: > At least the --fast-math part causes problems, seeing that PostgreSQL > actually checks for the __FAST_MATH__ macro to make sure that it isn't > turned on. There might be other problems with Apple's flags, but I > think that the __FAST_MATH__ check s