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

Re: Attempt at work around of int4 query won't touch int8 index ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk>
Cc: "pgsql-performance (at) postgresql (dot) org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Attempt at work around of int4 query won't touch int8 index ...
Date: 2003-09-16 14:05:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk> writes:
> On 15/09/2003 08:42 Shridhar Daithankar wrote:
>> Is it possible to follow data type upgrade model in planner?

We have one, more or less.  It's not explicitly coded, it emerges from
the fact that certain casts are implicit and others are not.  For
instance, int4->float8 is implicit but float8->int4 is not.

> Interestingly, float8 indexes do work OK (float8col = 99). I spend a large 
> part of yesterday grepping through the sources to try and find out why 
> this should be so. No luck so far but I'm going to keep on trying!

The reason that case works is that there is no float8 = int4 operator.
The parser can find no other interpretation than promoting the int4 to
float8 and using float8 = float8.  (The dual possibility, coerce float8
to int4 and use int4 = int4, is not considered because that coercion
direction is not implicit.)  So you end up with an operator that matches
the float8 index, and all is well.

The int8 case fails because there is a cross-type operator int8 = int4,
and the parser prefers that since it's an exact match to the initial
data types.  But it doesn't match the int8 index.

We've floated various proposals for solving this, such as getting rid of
cross-type operators, but none so far have passed the test of not having
bad side-effects.  See the pg_hackers archives for details (and *please*
don't waste this list's bandwidth with speculating about solutions until
you've absorbed some of the history.  This topic has been heard of
before ;-).)

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Joseph BoveDate: 2003-09-16 15:21:00
Subject: Re: Inconsistent performance
Previous:From: Vivek KheraDate: 2003-09-16 13:59:14
Subject: Re: restore time: sort_mem vs. checkpoing_segments

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