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
. Still, the 8-minute query time seems excessive.
On Mon, 17 Oct 2005 18:45:38 +0100, Richard Huxton wrote:
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
on
lead. I don't understand why it isn't being used.
Thanks for your help,
Martin Nickel
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)
-- takes 510,145 ms
EXPLAIN
Hello all,
Mostly Postgres makes sense to me. But now and then it does something
that boggles my brain. Take the statements below. I have a table
(agent) with 5300 rows. The primary key is agent_id. I can do SELECT
agent_id FROM agent and it returns all PK values in less than half a
second
.
The reason I ask is because I occasionally see large-ish queries take
forever (like cancel-after-12-hours forever) and wondered if this could
result from shared_buffers being too large.
Thanks for your (and anyone else's) help!
Martin Nickel
On Tue, 30 Aug 2005 10:08:21 +0800, Christopher Kings-Lynne
