Re: [PERFORM] [pgsql-hackers-win32] Performance on Win32 vs Cygwin

2004-10-14 Thread Magnus Hagander
Hi, We are experiencing slow performance on 8 Beta 2 Dev3 on Win32 and are trying to determine why. Any info is appreciated. We have a Web Server and a DB server both running Win2KServer with all service packs and critical updates. An ASP page on the Web Server hits the DB Server with a simple

[PERFORM] Performance vs Schemas

2004-10-14 Thread Igor Maciel Macaubas
Hi all, I recently migrated my database from schema 'public' to multiple schema. I have around 100 tables, and divided them in 14different schemas, and then adapted my application to use schemas as well. I could percept that the query / insert/ update times get pretty much faster then when

Re: [PERFORM] Performance vs Schemas

2004-10-14 Thread Gregory S. Williamson
Igor, I'm not sure if it is proper to state that schemas are themselves speeding things up. As an example, we have data that is usually accessed by county; when we put all of the data into one big table and select from it using a code for a county of interest, the process is fairly slow as

Re: [PERFORM] Excessive context switching on SMP Xeons

2004-10-14 Thread Dave Cramer
Bill, In order to manifest the context switch problem you will definitely require clients to be set to more than one in pgbench. It only occurs when 2 or more backends need access to shared memory. If you want help backpatching Gavin's patch I'll be glad to do it for you, but you do need a

[PERFORM] View Query Performance

2004-10-14 Thread Igor Maciel Macaubas
Hi all, I'm trying to find smarter ways to dig data from my database, and have the following scenario: table1 -- id -- name . . . . . . table2 -- id -- number . . . . . . I want to create a view to give me back just what I want: The id, the name and the number. I tought in doing the

Re: [PERFORM] First set of OSDL Shared Mem scalability results, some wierdness ...

2004-10-14 Thread Simon Riggs
First off, I'd like to get involved with these tests - pressure of other work only has prevented me. Here's my take on the results so far: I think taking the ratio of the memory allocated to shared_buffers against the total memory available on the server is completely fallacious. That is why

Re: [PERFORM] First set of OSDL Shared Mem scalability results, some wierdness ...

2004-10-14 Thread Josh Berkus
Simon, lots of good stuff clipped If you draw a graph of speedup (y) against cache size as a % of total database size, the graph looks like an upside-down L - i.e. the graph rises steeply as you give it more memory, then turns sharply at a particular point, after which it flattens out. The

Re: [Testperf-general] Re: [PERFORM] First set of OSDL Shared Mem

2004-10-14 Thread Timothy D. Witham
On Thu, 2004-10-14 at 16:57 -0700, Josh Berkus wrote: Simon, lots of good stuff clipped If you draw a graph of speedup (y) against cache size as a % of total database size, the graph looks like an upside-down L - i.e. the graph rises steeply as you give it more memory, then turns

Re: [PERFORM] Performance vs Schemas

2004-10-14 Thread Neil Conway
On Fri, 2004-10-15 at 04:38, Igor Maciel Macaubas wrote: I have around 100 tables, and divided them in 14 different schemas, and then adapted my application to use schemas as well. I could percept that the query / insert / update times get pretty much faster then when I was using the old

Re: [PERFORM] mmap (was First set of OSDL Shared Mem scalability results, some wierdness ...

2004-10-14 Thread Kevin Brown
Aaron Werman wrote: pg to my mind is unique in not trying to avoid OS buffering. Other dbmses spend a substantial effort to create a virtual OS (task management, I/O drivers, etc.) both in code and support. Choosing mmap seems such a limiting an option - it adds OS dependency and limits

Re: [PERFORM] First set of OSDL Shared Mem scalability results, some wierdness ...

2004-10-14 Thread Christopher Browne
Quoth [EMAIL PROTECTED] (Simon Riggs): I say this: ARC in 8.0 PostgreSQL allows us to sensibly allocate as large a shared_buffers cache as is required by the database workload, and this should not be constrained to a small percentage of server RAM. I don't think that this particularly follows

Re: [PERFORM] First set of OSDL Shared Mem scalability results, some wierdness ...

2004-10-14 Thread Tom Lane
Kevin Brown [EMAIL PROTECTED] writes: Hmm...something just occurred to me about this. Would a hybrid approach be possible? That is, use mmap() to handle reads, and use write() to handle writes? Nope. Have you read the specs regarding mmap-vs-stdio synchronization? Basically it says that