On Thursday 24 June 2010 15:16:05 Janning wrote:
> On Thursday 24 June 2010 14:53:57 Matthew Wakeling wrote:
> > On Thu, 24 Jun 2010, Janning wrote:
> > > We have a 12 GB RAM machine with intel i7-975 and using
> > > 3 disks "Seagate Barracuda 7200.11, ST31500341AS (1.5 TB)"
> > >
> > For each driv
Am Montag, 11. Oktober 2004 22:49 schrieb Francisco Reyes:
> On Mon, 11 Oct 2004, Janning Vygen wrote:
> > postgres uses a seq scan if its faster. In your case postgres seems to
> > know that most of your rows have a date < 2004-01-01 and so doesn't need
> > to consul
Am Mittwoch, 6. Oktober 2004 09:31 schrieben Sie:
> postgres=# explain ANALYZE select * from test where today < '2004-01-01';
> QUERY PLAN
>- Seq Scan on test (cost=0.00..19.51 rows=334
> width=44) (actual
> time=0.545..2.429 row
Am Dienstag, 5. Oktober 2004 08:49 schrieb Chris Hutchinson:
> Running a trivial query in v7.4.2 (installed with fedora core2) using
> EXPLAIN ANALYZE is taking considerably longer than just running the query
> (2mins vs 6 secs). I was using this query to quickly compare a couple of
> systems after
Hi,
(pg_version 7.4.2, i do run vacuum analyze on the whole database frequently
and just before executing statements below)
i dont know if anyone can help me because i dont know really where the problem
is, but i try. If any further information is needed i'll be glad to send.
my real rule much
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 non-s
