On Fri, 1 Jul 2005, Sam Mason wrote:
The key thing with the query that Sam have is that if you turn off seqscan
you get the first plan that run in 0.4ms and if seqscan is on the runtime
is 27851ms.
There are 100 way to make it select the seq scan, including rewriting the
query to something more
Emil Briggs wrote:
I just mentioned random_page_cost, but you should also tune
effective_cache_size, since that is effectively most of your RAM. It
depends what else is going on in the system, but setting it as high as
say 12-14GB is probably reasonable if it is a dedicated machine. With
random_
Emil Briggs wrote:
I'm working with an application where the database is entirely resident in RAM
(the server is a quad opteron with 16GBytes of memory). It's a web
application and handles a high volume of queries. The planner seems to be
generating poor plans for some of our queries which I ca
On Fri, Jul 01, 2005 at 09:59:38PM -0400, Emil Briggs wrote:
> I'm working with an application where the database is entirely resident in
> RAM
> (the server is a quad opteron with 16GBytes of memory). It's a web
> application and handles a high volume of queries. The planner seems to be
> gen
I'm working with an application where the database is entirely resident in RAM
(the server is a quad opteron with 16GBytes of memory). It's a web
application and handles a high volume of queries. The planner seems to be
generating poor plans for some of our queries which I can fix by raising
Dennis,
On Fri, 01 Jul 2005, Dennis Bjorklund wrote:
> On Thu, 30 Jun 2005, John Mendenhall wrote:
>
> > Our setting for effective_cache_size is 2048.
> >
> > random_page_cost = 4, effective_cache_size = 2048 time approximately
> > 4500ms
> > random_page_cost = 3, effective_cache_size = 2048
John A Meinel wrote:
>Why are you using LIMIT without having an ORDER BY?
I'm just exploring the data, trying to figure out what it's like.
>It just seems like this query isn't very useful. As it doesn't restrict
>by animal id, and it just gets 10 randomly selected animals where
>m.mtypeid=0.
Yu
Sam Mason wrote:
Hi,
I've just been referred here after a conversion on IRC and everybody
seemed to think I've stumbled upon some strangeness.
The planner (in PG version 8.0.2) is choosing what it thinks is a more
expensive plan. I've got a table of animals (about 3M rows) and their
movements
Tom Lane wrote:
>I fooled around trying to duplicate this behavior, without success.
>Can you create a self-contained test case?
I'll try and see if I can put something together, it's probably
going to be early next week though. I wont be able to give you our
data, so I'll be a bit of a headscrat
Sam Mason <[EMAIL PROTECTED]> writes:
> The planner (in PG version 8.0.2) is choosing what it thinks is a more
> expensive plan.
I fooled around trying to duplicate this behavior, without success.
Can you create a self-contained test case?
regards, tom lane
--
Hi,
I've just been referred here after a conversion on IRC and everybody
seemed to think I've stumbled upon some strangeness.
The planner (in PG version 8.0.2) is choosing what it thinks is a more
expensive plan. I've got a table of animals (about 3M rows) and their
movements (about 16M rows), a
On Thu, 30 Jun 2005, John Mendenhall wrote:
> Our setting for effective_cache_size is 2048.
>
> random_page_cost = 4, effective_cache_size = 2048 time approximately 4500ms
> random_page_cost = 3, effective_cache_size = 2048 time approximately 1050ms
> random_page_cost = 3, effective_cache_siz
12 matches
Mail list logo
