Re: [PERFORM] Shared buffers, Sort memory, Effective Cache Size

2004-04-27 Thread Manfred Koizar
On Wed, 21 Apr 2004 10:01:30 -0700, Qing Zhao [EMAIL PROTECTED] wrote: I have recently configured my PG7.3 on a G5 (8GB RAM) with shmmax set to 512MB and shared_buffer=5, sort_mem=4096 and effective cache size = 1. It seems working great so far but I am wondering if I should make effctive

Re: [PERFORM] planner/optimizer question

2004-04-27 Thread Atesz
Hi, You should try the next queries: select support_person_id from ticket_crm_map where crm_id = 7 GROUP BY support_person_id; select support_person_id from ticket_crm_map where crm_id = 1 GROUP BY support_person_id; It can use the 'ticket_crm_map_crm_id_suppid' index. Generally the Postgres

[PERFORM] Join problem

2004-04-27 Thread Silke Trissl
Hi, I came across a very intriguing thing: I had to join two tables and in both tables I wanted to restrict the result set by some (text/varchar) attributes. Here is an example: Table item # 147 000 entries Column | Type | Modifiers

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

2004-04-27 Thread Josh Berkus
Dave, Are you testing this with Tom's code, you need to do a baseline measurement with 10 and then increase it, you will still get lots of cs, but it will be less. No, that was just a test of 1000 straight up.Tom outlined a method, but I didn't see any code that would help me find a

Re: [PERFORM] OT: Help with performance problems

2004-04-27 Thread scott.marlowe
On Mon, 26 Apr 2004, Rob Fielding wrote: scott.marlowe wrote: On Fri, 23 Apr 2004, Chris Hoover wrote: DB's on Powervaults 220S using raid 5 (over 6 disks) What controller is this, the adaptec? We've found it to be slower than the LSI megaraid based controller, but YMMV.

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

2004-04-27 Thread Dave Cramer
Josh, I think you can safely increase by orders of magnitude here, instead of by +100, my wild ass guess is that the sweet spot is the spin time should be approximately the time it takes to consume the resource. So if you have a really fast machine then the spin count should be higher. Also you

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

2004-04-27 Thread Josh Berkus
Dave, But... you need a baseline first. A baseline on CS? I have that -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

[PERFORM] Simply join in PostrgeSQL takes too long

2004-04-27 Thread Vitaly Belman
Hello pgsql-performance, I discussed the whole subject for some time in DevShed and didn't achieve much (as for results). I wonder if any of you guys can help out: http://forums.devshed.com/t136202/s.html Regards, Vitaly Belman ICQ: 1912453 AIM: VitalyB1984 MSN: [EMAIL PROTECTED]

Re: [PERFORM] Simply join in PostrgeSQL takes too long

2004-04-27 Thread Nick Barr
Vitaly Belman wrote: Hello pgsql-performance, I discussed the whole subject for some time in DevShed and didn't achieve much (as for results). I wonder if any of you guys can help out: http://forums.devshed.com/t136202/s.html So cutting and pasting: - SCHEMA - CREATE TABLE

Re: [PERFORM] Simply join in PostrgeSQL takes too long

2004-04-27 Thread Atesz
Hi, You can try some variation: SELECT book_id FROM bookgenres, genre_children WHERE bookgenres.genre_id = genre_children.genre_child_id AND genre_children.genre_id = 1 GROUP BY book_id LIMIT 10 The next works if the 'genre_child_id' is UNIQUE on the 'genre_children' table.

Re: [PERFORM] Simply join in PostrgeSQL takes too long

2004-04-27 Thread Rod Taylor
On Tue, 2004-04-27 at 17:27, Vitaly Belman wrote: Hello pgsql-performance, I discussed the whole subject for some time in DevShed and didn't achieve much (as for results). I wonder if any of you guys can help out: http://forums.devshed.com/t136202/s.html You're taking the wrong

Re: [PERFORM] planner/optimizer question

2004-04-27 Thread Tom Lane
[EMAIL PROTECTED] writes: ... Wouldn't the most efficient plan be to scan the index regardless of crm_id because the only columns needed are in the index? No. People coming from other databases often have the misconception that queries can be answered by looking only at an index. That is

Re: [JDBC] [PERFORM] is a good practice to create an index on the

2004-04-27 Thread Dave Cramer
AFAIK, oids aren't used for anything internally, so duplicates don't really matter. Besides, what would you do about duplicate oid's ? The best suggestion is of course his last, don't use them. On Mon, 2004-04-26 at 22:48, Christopher Kings-Lynne wrote: I am using the oid of the table as the

Re: [JDBC] [PERFORM] is a good practice to create an index on the

2004-04-27 Thread Christopher Kings-Lynne
AFAIK, oids aren't used for anything internally, so duplicates don't really matter. Besides, what would you do about duplicate oid's ? If he's using them _externally_, then he does have to worry about duplicates. Chris ---(end of broadcast)--- TIP

Re: [JDBC] [PERFORM] is a good practice to create an index on the

2004-04-27 Thread Christopher Kings-Lynne
I am going to use them as primary key of the table, so I'll surely need them unique :) Eduoardo, I REALLY suggest you don't use them at all. You should make a primary key like this: CREATE TABLE blah ( id SERIAL PRIMARY KEY, ... ); Also note that by default, OIDs are NOT dumped by pg_dump.