From: | "Tim Jones" <TJones(at)optio(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: strange query behavior |
Date: | 2006-12-13 22:08:44 |
Message-ID: | 47668A1334CDBF46927C1A0DFEB223D39F7A98@mail.optiosoftware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Version 8.1
Here are the planner constraints I believe we changed
effective_cache_size and random_page_cost
BTW this is an AIX 5.2
#-----------------------------------------------------------------------
----
# QUERY TUNING
#-----------------------------------------------------------------------
----
# - Planner Method Configuration -
#enable_bitmapscan = on
#enable_hashagg = on
#enable_hashjoin = on
#enable_indexscan = on
#enable_mergejoin = on
#enable_nestloop = on
#enable_seqscan = on
#enable_sort = on
#enable_tidscan = on
# - Planner Cost Constants -
#effective_cache_size = 10000 # typically 8KB each
effective_cache_size = 400000
random_page_cost = 3.8 # units are one sequential page fetch
# cost
#cpu_tuple_cost = 0.01 # (same)
#cpu_index_tuple_cost = 0.001 # (same)
#cpu_operator_cost = 0.0025 # (same)
# - Genetic Query Optimizer -
#geqo = on
#geqo_threshold = 12
#geqo_effort = 5 # range 1-10
#geqo_pool_size = 0 # selects default based on effort
#geqo_generations = 0 # selects default based on effort
#geqo_selection_bias = 2.0 # range 1.5-2.0
# - Other Planner Options -
#default_statistics_target = 10 # range 1-1000
#constraint_exclusion = off
#from_collapse_limit = 8
#join_collapse_limit = 8 # 1 disables collapsing of explicit
# JOINs
Thanks
Tim Jones
Healthcare Project Manager
Optio Software, Inc.
(770) 576-3555
-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, December 13, 2006 4:59 PM
To: Tim Jones
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] strange query behavior
"Tim Jones" <TJones(at)optio(dot)com> writes:
> The tables for theses queries are vacuumed and analyzed regularly. I
> just did an analyze to be sure and here are the results ...
There's something pretty wacko about the choice of plan in the slow case
--- I don't see why it'd not have used the same plan structure as for
the IN case. It's coming up with a cost a lot higher than for the
other, so it certainly knows this isn't a great plan ...
Which PG version is this exactly? Are you running with any nondefault
planner parameters?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | James Cloos | 2006-12-13 22:35:26 | Re: Optimizing a query |
Previous Message | Tom Lane | 2006-12-13 21:58:55 | Re: strange query behavior |