Re: [PERFORM] Persistent Connections

2004-04-20 Thread Thomas Swan
Randolf Richardson wrote: "[EMAIL PROTECTED] (Nick Barr)" stated in comp.databases.postgresql.performance: [EMAIL PROTECTED] wrote: [sNip] Sorry I m a little bit confused about the persistent thing!! Is it smart to use persistent connections at all if i expect 100K Users to hit the s

Re: [PERFORM] The black art of postgresql.conf tweaking

2004-08-04 Thread Thomas Swan
Janning Vygen wrote: Am Mittwoch, 4. August 2004 14:45 schrieb Paul Serby: Apache on the Web server can take up to 300 connections and PHP is using pg_pconnect Postgres is set with the following. max_connections = 300 shared_buffers = 38400 sort_mem = 12000 But Apache is still maxing out the no

Re: [PERFORM] I could not get postgres to utilizy indexes

2004-08-18 Thread Thomas Swan
Igor Artimenko wrote: Hi verybody! I can't make use of indexes even I tried the same test by changing different settings in postgres.conf like geqo to off/on & geqo related parameters, enable_seqscan off/on & so on. Result is the same. Here is test itself: I've created simplest table test and exe

Re: [PERFORM] VACUUM ANALYZE downgrades performance

2004-11-30 Thread Thomas Swan
On 11/30/2004 7:30 AM Dmitry Karasik said:: Hi all, On v7.4.5 I noticed downgrade in the planner, namely favoring sequential scan over index scan. The proof: create table a ( a integer); create index aidx on a(a); explain analyze select * from a where a = 0; -- Index Scan using aidx on a (

Re: [PERFORM] Memory question

2003-06-29 Thread Thomas Swan
Arjen van der Meijden wrote: I've heard that too, but it doesn't seem to make much sense to me. If you get to the point where your machine is _needing_ 2GB of swap then something has gone horribly wrong (or you just need more RAM in the machine) and it will just crawl until the kernel kills o

Re: [PERFORM] slow plan for min/max

2003-09-09 Thread Thomas Swan
Tom Lane wrote: >"scott.marlowe" <[EMAIL PROTECTED]> writes: > > >>On Mon, 8 Sep 2003, Neil Conway wrote: >> >> >>>As was pointed out in a thread a couple days ago, MIN/MAX() optimization >>>has absolutely nothing to do with MVCC. It does, however, make >>>optimizing COUNT() more difficult.

Re: [PERFORM] Compare rows

2003-10-10 Thread Thomas Swan
I took this approach with a former company in designing an dynamic e-commerce system. This kept the addition of new products from requiring an alteration of the schema. With an ORB manager and cache control the performance was not significantly, but the automatic extensibility and the ease

Re: [PERFORM] PostgreSQL vs MySQL

2003-10-10 Thread Thomas Swan
David Griffiths wrote: This is a timely thread for myself, as I'm in the middle of testing both databases as an Oracle replacement. As of this moment, I know more about MySQL (tuning, setup, features) than I do about Postgres. Not because I like MySQL more, but because 1) the MySQL docs are

Re: [PERFORM] 100 simultaneous connections, critical limit?

2004-01-15 Thread Thomas Swan
scott.marlowe wrote: >On Wed, 14 Jan 2004, Adam Alkins wrote: > > > >>scott.marlowe wrote: >> >> >> >>>A few tips from an old PHP/Apache/Postgresql developer. >>> >>>1: Avoid pg_pconnect unless you are certain you have load tested the >>>system and it will behave properly. pg_pconnect ofte