On Mon, Feb 28, 2011 at 02:04:53PM -0500, Robert Haas wrote:
On Sun, Feb 27, 2011 at 1:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus j...@agliodbs.com wrote:
I'm not saying that PostgreSQL couldn't do better
On Sun, Feb 27, 2011 at 1:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus j...@agliodbs.com wrote:
I'm not saying that PostgreSQL couldn't do better on this kind of case,
but that doing better is a major project,
On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus j...@agliodbs.com wrote:
Laszlo,
Which is silly. I think that PostgreSQL converts the int side to a
float, and then compares them.
It would be better to do this, for each item in the loop:
* evaluate the right side (which is float)
*
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus j...@agliodbs.com wrote:
I'm not saying that PostgreSQL couldn't do better on this kind of case,
but that doing better is a major project, not a minor one.
Specifically, the problem is that x = 4.0, where x
09.02.11 01:14, Dave Crooke написав(ла):
You will get the same behaviour from any database product where the
query as written requires type coercion - the coercion has to go in
the direction of the wider type. I have seen the exact same scenario
with Oracle, and I view it as a problem with the
This query:
select p.id,p.producer_id,visa.variation_item_id, vi.qtyavail
from variation_item_sellingsite_asin visa
inner join product p on p.id = visa.product_id
inner join variation_item vi on vi.id =
Laszlo,
Which is silly. I think that PostgreSQL converts the int side to a
float, and then compares them.
It would be better to do this, for each item in the loop:
* evaluate the right side (which is float)
* tell if it is an integer or not
* if not an integer, then discard
You will get the same behaviour from any database product where the query as
written requires type coercion - the coercion has to go in the direction of
the wider type. I have seen the exact same scenario with Oracle, and I
view it as a problem with the way the query is written, not with the
