Message-ID: <4863359C.1040906@emolecules.com>
Date: Wed, 25 Jun 2008 23:22:20 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org
Subject: Re: Typecast bug?
References: 
 <D960CB61B694CF459DCFB4B0128514C201FA62C8@exadv11.host.magwien.gv.at>
	<C050E63A-2209-4E89-AA99-6A327CCE7380@torgo.978.org>
	<Pine.LNX.4.64.0804111736580.20402@aragorn.flymine.org>
	<47FFA7FF.10801@postnewspapers.com.au>
	<544D07A2-EB3F-4D91-A749-0C4D5D38AB80@gmail.com>
	<481F992D.7070509@emolecules.com>
	<Pine.GSO.4.64.0805052354120.3752@westnet.com>
	<4820A3C2.4000307@emolecules.com>
	<Pine.GSO.4.64.0805061605030.11474@westnet.com>
	<4820C30A.8010709@emolecules.com>
	<D960CB61B694CF459DCFB4B0128514C202122018@exadv11.host.magwien.gv.at>
	<4863186E.1000306@emolecules.com> <5564.1214458410@sss.pgh.pa.us>
In-Reply-To: <5564.1214458410@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Craig James <craig_james@emolecules.com> writes:
>> This seems like a bug to me, but it shows up as a performance problem.
> 
>> emol_warehouse_1=> explain analyze select version_id, parent_id from version where version_id = 999999999999999999999999999;
> 
> If you actually *need* so many 9's here as to force it out of the range
> of bigint, then why is your id column not declared numeric?
> 
> This seems to me to be about on par with complaining that "intcol = 4.2e1"
> won't be indexed.  We have a numeric data type hierarchy, learn to
> work with it ...

Your suggestion of "learn to work with it" doesn't fly.  A good design separates the database schema details from the application to the greatest extent possible.  What you're suggesting is that every application that queries against a Postgres database should know the exact range of every numeric data type of every indexed column in the schema, simply because Postgres can't recognize an out-of-range numeric value.

In this case, the optimizer could have instantly returned zero results with no further work, since the query was out of range for that column.

This seems like a pretty simple optimization to me, and it seems like a helpful suggestion to make to this forum.

BTW, this query came from throwing lots of junk at a web app in an effort to uncover exactly this sort of problem.  It's not a real query, but then, hackers don't use real queries.  The app checks that its input is a well-formed integer expression, but then assumes Postgres can deal with it from there.

Craig