Re: [PERFORM] Optimize

2003-11-25 Thread Shridhar Daithankar
Torsten Schulz wrote: Chester Kustarz wrote: On Mon, 24 Nov 2003, Torsten Schulz wrote: shared_buffers = 5000# 2*max_connections, min 16 that looks pretty small. that would only be 40MBytes (8k/page * 5000pages). http://www.varlena.com/GeneralBits/Tidbits/perf.html Ok, thats it. I've set

Re: [PERFORM] Impossibly slow DELETEs

2003-11-25 Thread Tom Lane
Neil Conway <[EMAIL PROTECTED]> writes: >> There are 6 rows in the table (given that size, I assumed that an >> index was not necessary). > That's a reasonable assumption. But if he's updated those rows a few hundred thousand times and never VACUUMed, he could be having some problems ...

Re: [PERFORM] Impossibly slow DELETEs

2003-11-25 Thread Neil Conway
Stefan Champailler <[EMAIL PROTECTED]> writes: > So here's my trouble : some DELETE statement take up to 1 minute to > complete (but not always, sometimes it's fast, sometimes it's that > slow). Here's a typical one : DELETE FROM response_bool WHERE > response_id = '125' The response_bool table has

Re: [PERFORM] Wierd context-switching issue on Xeon

2003-11-25 Thread Josh Berkus
Tom, > Strictly a WAG ... but what this sounds like to me is disastrously bad > behavior of the spinlock code under heavy contention. We thought we'd > fixed the spinlock code for SMP machines awhile ago, but maybe > hyperthreading opens some new vistas for misbehavior ... Yeah, I thought of tha

Re: [PERFORM] Impossibly slow DELETEs

2003-11-25 Thread Bill Moran
Stefan Champailler wrote: Dear You all, (please tell me if this has already been discussed, I was unable to find any convincing information) I'm developing a small application, tied to a PG 7.4 beta 5 (i didn't upgrade). The DB i use is roughly 20 tales each of them containing at most 30 recor

Re: [PERFORM] Wierd context-switching issue on Xeon

2003-11-25 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > We're seeing some odd issues with hyperthreading-capable Xeons, whether or not > hyperthreading is enabled. Basically, when a small number of really-heavy > duty queries hit the system and push all of the CPUs to more than 70% used > (about 1/2 user &

[PERFORM] Wierd context-switching issue on Xeon

2003-11-25 Thread Josh Berkus
Folks, We're seeing some odd issues with hyperthreading-capable Xeons, whether or not hyperthreading is enabled. Basically, when a small number of really-heavy duty queries hit the system and push all of the CPUs to more than 70% used (about 1/2 user & 1/2 kernel), the system goes to 100,000+

Re: [PERFORM] [Fwd: Re: Optimize]

2003-11-25 Thread Russell Garrett
>>> with this query I see how much queries running, but the field >>> current_query are free, so i can't see which queries are very slow. >> >> >> You must perform that query with permission of super_user. >> > I've made it in root-account with psql -U postgres - but i can't see > the query You m

Re: [PERFORM] Optimize

2003-11-25 Thread Torsten Schulz
Chester Kustarz wrote: On Mon, 24 Nov 2003, Torsten Schulz wrote: shared_buffers = 5000# 2*max_connections, min 16 that looks pretty small. that would only be 40MBytes (8k/page * 5000pages). http://www.varlena.com/GeneralBits/Tidbits/perf.html Ok, thats it. I've set it to 512

Re: [PERFORM] [Fwd: Re: Optimize]

2003-11-25 Thread Torsten Schulz
Gaetano Mendola wrote: Torsten Schulz wrote: Hi, You can see doing select * from pg_stat_activity the queries that are currently running on your server, and do a explain analize on it to see which one is the bottleneck. If you are running the 7.4 you can see on the log the total ammount for ea

[PERFORM] Impossibly slow DELETEs

2003-11-25 Thread Stefan Champailler
Dear You all, (please tell me if this has already been discussed, I was unable to find any convincing information) I'm developing a small application, tied to a PG 7.4 beta 5 (i didn't upgrade). The DB i use is roughly 20 tales each of them containing at most 30 records (I'm still in developme

Re: [PERFORM] why index scan not working when using 'like'?

2003-11-25 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > In regular text fields containing words, your problem is solvable with full > text indexing (FTI). Unfortunately, FTI is not designed for arbitrary > non-language strings. It could be adapted, but would require a lot of > hacking. I'm not sure why yo

Re: [PERFORM] [Fwd: Re: Optimize]

2003-11-25 Thread Gaetano Mendola
Torsten Schulz wrote: Hi, You can see doing select * from pg_stat_activity the queries that are currently running on your server, and do a explain analize on it to see which one is the bottleneck. If you are running the 7.4 you can see on the log the total ammount for each query. with this que

Re: [PERFORM] why index scan not working when using 'like'?

2003-11-25 Thread Josh Berkus
Lianhe, > I want to use index on the gene_symbol column in my > query and gene_symbol is indexed. but when I use > lower (gene_symbol) like lower('%mif%'), the index > is not used. While when I change to > lower(gene_symbol) = lower('mif'), the index is used > and index scan works, but this is not

Re: [PERFORM] why index scan not working when using 'like'?

2003-11-25 Thread Dror Matalon
Hi, Searches with like or regexes often can't use the index. Think of the index as a sorted list of your items. It's easy to find an item when you know it starts with mif so ('mif%' should use the index). But when you use a 'like' that starts with '%' the index is useless and the search needs to

[PERFORM] why index scan not working when using 'like'?

2003-11-25 Thread LIANHE SHAO
Hi all, I want to use index on the gene_symbol column in my query and gene_symbol is indexed. but when I use lower (gene_symbol) like lower('%mif%'), the index is not used. While when I change to lower(gene_symbol) = lower('mif'), the index is used and index scan works, but this is not what I like

[Fwd: Re: [PERFORM] Optimize]

2003-11-25 Thread Torsten Schulz
Hi, You can see doing select * from pg_stat_activity the queries that are currently running on your server, and do a explain analize on it to see which one is the bottleneck. If you are running the 7.4 you can see on the log the total ammount for each query. with this query I see how much quer

Re: [PERFORM] design question: general db performance

2003-11-25 Thread Richard Huxton
On Tuesday 25 November 2003 18:42, shane hill wrote: > > Our db is getting to be a respectable size (about 10GB right now) and is > growing slower and slower. I have been charged with making it faster and > with a smaller footprint while retaining all of the current > functionality. here is one of

Re: [PERFORM] design question: general db performance

2003-11-25 Thread Jeff
On Tue, 25 Nov 2003 10:42:47 -0800 shane hill <[EMAIL PROTECTED]> wrote: > Our db is getting to be a respectable size (about 10GB right now) and > is growing slower and slower. I have been charged with making it > faster and with a smaller footprint while retaining all of the current > functionali

Re: [PERFORM] design question: general db performance

2003-11-25 Thread Josh Berkus
Shane, > Disclaimer: I am relatively new to RDBMSs, so please do not laugh at me > too loudly, you can laugh, just not too loudly and please do not point. :) Hey, we all started somewhere. Nobody was born knowing databases. Except maybe Neil Conway. > I am working on an Automated Installer

Re: [PERFORM] design question: general db performance

2003-11-25 Thread Jord Tanner
[small chuckle] By George, I think he's got it! You are on the right track. Have a look at this link on database normalization for more info: http://databases.about.com/library/weekly/aa080501a.htm On Tue, 2003-11-25 at 10:42, shane hill wrote: > Hi folks, > > Disclaimer: I am relatively n

[PERFORM] design question: general db performance

2003-11-25 Thread shane hill
Hi folks, Disclaimer: I am relatively new to RDBMSs, so please do not laugh at me too loudly, you can laugh, just not too loudly and please do not point. :) I am working on an Automated Installer Testing System for Adobe Systems and I am doing a DB redesign of the current postgres db: 1. We

Re: [PERFORM] Where to start for performance problem?

2003-11-25 Thread Tom Lane
MK Spam <[EMAIL PROTECTED]> wrote: > ... the problem we are having is gradually degrading > performance ending in postgres shutting down. As someone else commented, that's not an ordinary sort of performance problem. What exactly happens when the database "shuts down"? re

Re: [PERFORM] Where to start for performance problem?

2003-11-25 Thread Bruno Wolff III
On Mon, Nov 24, 2003 at 16:03:17 -0600, MK Spam <[EMAIL PROTECTED]> wrote: > > The archives of this list provides many ideas for improving performance, but the > problem we are having is gradually degrading performance ending in postgres shutting > down. So it's not a matter of optimizing a c

Re: [PERFORM] Maximum Possible Insert Performance?

2003-11-25 Thread Tom Lane
Shridhar Daithankar <[EMAIL PROTECTED]> writes: > William Yu wrote: >> This is an intriguing thought which leads me to think about a similar >> solution for even a production server and that's a solid state drive for >> just the WAL. What's the max disk space the WAL would ever take up? > Maxim

Re: [PERFORM] Where to start for performance problem?

2003-11-25 Thread Rob Fielding
The problems with giving suggestions about increasing performance is that one persons increase is another persons decrease. having said that, there are a few general suggestions : Set-up some shared memory, about a tenth of your available RAM, and configure shared_memory and max_clients correct