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

Re: PostgreSQL giving jitters to Skypak

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Christopher Petrilli <petrilli(at)gmail(dot)com>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>,"Jussi(dot)Mikkola(at)bonware(dot)com" <jussi(dot)mikkola(at)bonware(dot)com>,aspire420(at)hotpop(dot)com, pgsql-advocacy(at)postgresql(dot)org,in(at)postgresql(dot)org
Subject: Re: PostgreSQL giving jitters to Skypak
Date: 2004-08-25 01:32:06
Message-ID: 20040824223143.W68447@ganymede.hub.org (view raw or flat)
Thread:
Lists: pgsql-advocacy
On Tue, 24 Aug 2004, Christopher Petrilli wrote:

> On Tue, 24 Aug 2004 20:11:13 -0300 (ADT), Marc G. Fournier
> <scrappy(at)postgresql(dot)org> wrote:
>> On Tue, 24 Aug 2004, Jussi(dot)Mikkola(at)bonware(dot)com wrote:
>>
>>> Hi !
>>>
>>> I think it would be a good idea to check how they are using indexes, and what
>>> the structure of the database is. Missing an index or two can affect quite
>>> much.
>>
>> As I'm experiencing with a client right now ... schema hurts alot too ...
>> all of their queries are bigint = int, so they are having to go through
>> their code and changing it to bigint = int::bigint so that indices are
>> being used properly ...
>
> I've always wondered... is there some reason we don't do "type
> promotion" to match indices? So if someone provides an int, and a
> bigint index exists, it should be used automatically, as they're
> interchangable (i.e. int is a subset of bigint).

This is fixed (or, partially addressed) in 8.0 ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org           Yahoo!: yscrappy              ICQ: 7615664

In response to

pgsql-advocacy by date

Next:From: Mark KirkwoodDate: 2004-08-25 05:32:48
Subject: Benchmark Results For Postgresql, Mysql, Firebird
Previous:From: Josh BerkusDate: 2004-08-25 01:09:42
Subject: Re: PostgreSQL giving jitters to Skypak

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