ence.
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, Christop
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 (d
ZE 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&#
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 ANA
ata
-page reads. 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.performan
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 c
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
I was reading a comment in another posting and it started me thinking
about this. Let's say I startup an Oracle server. All my queries are a
little bit (sometimes a lot bit) slow until it gets its "normal" things in
memory, then it's up to speed. The "normal" things would include some
small look
