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 time

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

Re: [PERFORM] Tuning shared_buffers with ipcs ?

2004-10-15 Thread Doug Y
Tom Lane wrote: Doug Y <[EMAIL PROTECTED]> writes: Tom Lane wrote: This might tell you something about how many concurrent backends you've used, but nothing about how many shared buffers you need. Thats strange, I know I've had more than 4 concurrent connections on

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/GeneralB

[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 tota

[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 trying

[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
nkar wrote: 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/varlen

[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)