Re: [PERFORM] vacuum analyze slows sql query

2004-11-03 Thread Doug Y
Given that the plan doesn't change after an analyze, my guess would be that the first query is hitting cached data, then you vacuum and that chews though all the cache with its own data pushing the good data out of the cache so it has to be re-fetched from disk. If you run the select a 2nd

Re: [PERFORM] Why isn't this index being used?

2004-10-19 Thread Doug Y
Hi, I ran into a similar problem using bigints... See: http://www.postgresql.org/docs/7.3/static/datatype.html#DATATYPE-INT small big int have to be cast when used in querries... try: explain select * from db where type=90::smallint and subtype=70::smallint and date='7/1/2004'; or explain select

[PERFORM] Tuning shared_buffers with ipcs ?

2004-10-15 Thread Doug Y
Hello, I've seen a couple references to using ipcs to help properly size shared_buffers. I don't claim to be a SA guru, so could someone help explain how to interpret the output of ipcs and how that relates to shared_buffers? How does one determine the size of the segment arrays? I see the

Re: [PERFORM] Tuning shared_buffers with ipcs ?

2004-10-15 Thread Doug Y
Tom Lane wrote: Doug Y [EMAIL PROTECTED] writes: I've seen a couple references to using ipcs to help properly size shared_buffers. I have not seen any such claim, and I do not see any way offhand that ipcs could help. Directly from: http://www.varlena.com/varlena/GeneralBits/Tidbits

[PERFORM] The never ending quest for clarity on shared_buffers

2004-10-06 Thread Doug Y
Hello, We recently upgraded os from rh 7.2 (2.4 kernel) to Suse 9.1 (2.6 kernel), and psql from 7.3.4 to 7.4.2 One of the quirks I've noticed is how the queries don't always have the same explain plans on the new psql... but that's a different email I think. My main question is I'm

[PERFORM] Interpreting vmstat

2004-05-18 Thread Doug Y
Hello, (note best viewed in fixed-width font) I'm still trying to find where my performance bottle neck is... I have 4G ram, PG 7.3.4 shared_buffers = 75000 effective_cache_size = 75000 Run a query I've been having trouble with and watch the output of vmstat (linux): $ vmstat 1 procs

Re: [PERFORM] Clarification on some settings

2004-05-13 Thread Doug Y
: Doug Y wrote: Hello, I've been having some performance issues with a DB I use. I'm trying to come up with some performance recommendations to send to the adminstrator. Ok for what I'm uncertain of... shared_buffers: According to http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html Its

[PERFORM] Clarification on some settings

2004-05-11 Thread Doug Y
Hello, I've been having some performance issues with a DB I use. I'm trying to come up with some performance recommendations to send to the adminstrator. Hardware: CPU0: Pentium III (Coppermine) 1000MHz (256k cache) CPU1: Pentium III (Coppermine) 1000MHz (256k cache) Memory: 3863468 kB (4 GB)