Martin Nickel wrote:
> On Tue, 18 Oct 2005 08:52:15 +0100, Richard Huxton wrote:
> > 3. Actually - are you happy that your general configuration is OK?
> We're running dual Opteron 244s with 4G of memory. The platform is
> Suse 9.3, 64 bit. The database is on a 3ware 9500S-8 sata raid controll
On Tue, 18 Oct 2005 08:52:15 +0100, Richard Huxton wrote:
> 3. Actually - are you happy that your general configuration is OK?
We're running dual Opteron 244s with 4G of memory. The platform is
Suse 9.3, 64 bit. The database is on a 3ware 9500S-8 sata raid controller
configured raid 10 with 4
On Tue, 18 Oct 2005 08:52:15 +0100, Richard Huxton wrote:
> Martin Nickel wrote:
>> When I turn of seqscan it does use the index - and it runs 20 to 30%
>> longer. Based on that, the planner is correctly choosing a sequential
>> scan - but that's just hard for me to comprehend. I'm joining on an
Martin Nickel wrote:
When I turn of seqscan it does use the index - and it runs 20 to 30%
longer. Based on that, the planner is correctly choosing a sequential
scan - but that's just hard for me to comprehend. I'm joining on an int4
key, 2048 per index page - I guess that's a lot of reads - the
When I turn of seqscan it does use the index - and it runs 20 to 30%
longer. Based on that, the planner is correctly choosing a sequential
scan - but that's just hard for me to comprehend. I'm joining on an int4
key, 2048 per index page - I guess that's a lot of reads - then the data
-page reads.
Martin Nickel wrote:
Subject: Re: Sequential scan on FK join
From: Martin Nickel <[EMAIL PROTECTED]>
Newsgroups: pgsql.performance
Date: Wed, 12 Oct 2005 15:53:35 -0500
Richard, here's the EXPLAIN ANALYZE. I see your point re: the 2.7M
expected vs the 2 actual, but I've r
Subject: Re: Sequential scan on FK join
From: Martin Nickel <[EMAIL PROTECTED]>
Newsgroups: pgsql.performance
Date: Wed, 12 Oct 2005 15:53:35 -0500
Richard, here's the EXPLAIN ANALYZE. I see your point re: the 2.7M
expected vs the 2 actual, but I've run ANALYZE on the lead
Martin Nickel wrote:
EXPLAIN SELECT m.mailcode, l.lead_id
FROM mailing m
INNER JOIN lead l ON m.mailing_id = l.mailing_id
WHERE (m.maildate >= '2005-7-01'::date
AND m.maildate < '2005-8-01'::date)
Hash Join (cost=62.13..2001702.55 rows=2711552 width=20)
Hash Cond: ("outer".m
All,
I can see why the query below is slow. The lead table is 34 million rows,
and a sequential scan always takes 3+ minutes. Mailing_id is the PK for
mailing and is constrained as a foreign key (NULLS allowed) in lead.
There is an index on lead.mailing_id. I've just run VACUUM ANALYZE on
lead
