pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Craig James <craig_james@emolecules.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-performance@postgresql.org
Subject: Re: Typecast bug?
Date: Wed, 25 Jun 2008 23:22:20 -0700
Message-ID: <4863359C.1040906@emolecules.com> (raw)
In-Reply-To: <5564.1214458410@sss.pgh.pa.us>
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>

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



view thread (5+ messages)  latest in thread

Message-ID: <4863359C.1040906@emolecules.com>
Permalink:  ../4863359C.1040906@emolecules.com/
Also on:    postgresql.org/message-id/4863359C.1040906@emolecules.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: craig_james@emolecules.com, tgl@sss.pgh.pa.us
  Subject: Re: Typecast bug?
  In-Reply-To: <4863359C.1040906@emolecules.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox