On Thu, Mar 5, 2009 at 12:58 PM, Joshua D. Drake wrote:
> What happens if you do this:
>
> SET cpu_tuple_cost TO '0.5';
> SET cpu_index_tuple_cost TO '0.5';
> EXPLAIN ANALYZE 8.3 query
>
> Next try this:
>
> SET cpu_tuple_cost TO '0.5';
> SET cpu_index_tuple_cost TO '0.5';
> SET seq_page_cost
On Thu, Mar 5, 2009 at 12:58 PM, Joshua D. Drake wrote:
> What happens if you do this:
>
> SET cpu_tuple_cost TO '0.5';
> SET cpu_index_tuple_cost TO '0.5';
> EXPLAIN ANALYZE 8.3 query
>
Right now, I'm getting very good results with the above. I'm still running
additional tests but I'll keep
Matching query plans with numerics changed to integers.
I sent the wrong query plans earlier
8.3.3: 1195 ms
8.2.12: 611 ms
2nd part of table descriptions
Table "public.company"
Column|Type | Modifiers
--+-+
id | integer | not null
Query and first part of the table descriptions
Query:
explain analyze
select distinct on
(t8.id) t8.id,
t8.payment_id,
t8.amount_id,
t8.active,
t8.or
On Tue, Mar 3, 2009 at 5:34 PM, Tom Lane wrote:
> Comparisons on
> numerics aren't terribly fast though (in either release). I wonder
> whether you could change the key columns to int or bigint.
I changed the affected columns from numeric to integers and I was unable to
get any performance gai
On Tue, Mar 3, 2009 at 12:38 PM, wrote:
> if you haven't done a vaccum analyse on either installation then postgres'
> idea of what sort of data is in the database is unpredictable, and as a
> result it's not surprising that the two systems guess differently about what
> sort of plan is going to
On Mon, Mar 2, 2009 at 10:23 PM, Tom Lane wrote:
> Are you sure you are comparing apples to apples here? Same configure
> options for the builds, same parameter values in postgresql.conf, both
> databases ANALYZEd, etc? And are they running on the same hardware?
>
Thank you for looking at this
Hi,
We are currently running postgres 8.2 and are evaluating the upgrade to 8.3.
Some of our tests are indicating that postgresql 8.3 is actually degrading
the
performance of some of our queries by a factor of 10 or more. The queries
in
question are selects that are heavy on joins (~10 tables) w
