Joey Smith <[EMAIL PROTECTED]> writes:
> EXPLAIN ANALYZE SELECT message_idnr FROM messages WHERE mailbox_idnr
> = 1746::bigint AND status<2::smallint AND seen_flag = 0 AND unique_id
> != '' ORDER BY message_idnr ASC LIMIT 1;
> QUERY P
Accidentally sent directly to Josh.
-- Forwarded message --
From: Joey Smith <[EMAIL PROTECTED]>
Date: Fri, 10 Sep 2004 15:57:49 -0600
Subject: Re: [PERFORM] Interesting performance behaviour
To: [EMAIL PROTECTED]
> > I see a similar speedup (and change in query
> > shared_buffers = 1000
> > sort_mem = 1024
> > effective_cache_size = 1000
>
> effective_cache_size should be much higher, like 3/4 of your available RAM.
> This is probably the essence of your planner problem; the planner thinks you
> have no RAM.
I set effective_cache_size to 64000 on a mach
Joey,
> shared_buffers = 1000
> sort_mem = 1024
> effective_cache_size = 1000
effective_cache_size should be much higher, like 3/4 of your available RAM.
This is probably the essence of your planner problem; the planner thinks you
have no RAM.
> I see a similar speedup (and change in query pl
#postgresql on Freenode recommended I post this here.
I'm seeing some odd behaviour with LIMIT. The query plans are included
here, as are the applicable table and index definitions. All table,
index, and query information can be found in a standard dbmail 1.2.6
install, if anyone wants to try sett
