Skip site navigation (1) Skip section navigation (2)

Re: Real vs Int performance

From: "Igor Neyman" <ineyman(at)perceptron(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"David Greco" <David_Greco(at)harte-hanks(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Real vs Int performance
Date: 2011-01-27 16:17:46
Message-ID: F4C27E77F7A33E4CA98C19A9DC6722A2070C23A0@EXCHANGE.corp.perceptron.com (view raw or flat)
Thread:
Lists: pgsql-performance
 

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] 
> Sent: Wednesday, January 26, 2011 5:12 PM
> To: David Greco
> Cc: pgsql-performance(at)postgresql(dot)org
> Subject: Re: Real vs Int performance 
> 
> David Greco <David_Greco(at)harte-hanks(dot)com> writes:
> > Came across a problem I find perplexing. I recreated the 
> dimensional 
> > tables in Oracle and the fields that are integers in Oracle became 
> > integers in Postgres. Was experiencing terrible performance 
> during the 
> > load and narrowed down to a particular dimensional lookup 
> problem. 
> .......................................
> .......................................
> .......................................
> .......................................
> In real life, this query is actually bound and parameterized,
> 
> In that case, an EXPLAIN using literal constants is next door 
> to useless in terms of telling you what will happen in real 
> life.  You need to pay attention to exactly how the 
> parameterization is done.  Again, I'm suspecting a wrong 
> datatype indication.
> 
> 			regards, tom lane
> 

To see what happens with parametrized query in "real life" you could try
"auto_explain" contrib module.

Regards,
Igor Neyman

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2011-01-27 16:40:47
Subject: Re: Postgres 9.0 has a bias against indexes
Previous:From: David WilsonDate: 2011-01-27 16:09:15
Subject: Re: Postgres 9.0 has a bias against indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group