Re: Query optimization using order by and limit

From: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Viscuso <michael(dot)viscuso(at)getcarbonblack(dot)com>, Greg Smith <greg(at)2ndQuadrant(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Query optimization using order by and limit
Date: 2011-09-22 13:41:25
Message-ID: 20110922134125.GJ30871@staff-mud-56-27.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Sep 21, 2011 at 11:22:53PM -0400, Tom Lane wrote:
> Michael Viscuso <michael(dot)viscuso(at)getcarbonblack(dot)com> writes:
> > Greg/Tom, you are correct, these columns should be modified to whatever
> > is easiest for Postgres to recognize 64-bit unsigned integers. Would
> > you still recommend bigint for unsigned integers? I likely read the
> > wrong documentation that suggested bigint for signed 64-bit integers and
> > numeric(20) for unsigned 64-bit integers.
>
> Unsigned? Oh, hm, that's a bit of a problem because we don't have any
> unsigned types. If you really need to go to 2^64 and not 2^63 then
> you're stuck with numeric ... but that last bit is costing ya a lot.
>
> regards, tom lane
>

Hi Michael,

If you have access to the application, you can map the unsigned 64-bits
to the PostgreSQL signed 64-bit type with a simple subtraction. That will
allow you to drop all the numeric use. Also if the guid is a 64-bit
values stuffed into a numeric(20), you can do it there as well. I achieved
a hefty performance boost by making those application level changes in a
similar situation.

Regards,
Ken

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Viscuso 2011-09-22 13:55:28 Re: Query optimization using order by and limit
Previous Message Gunnlaugur Þór Briem 2011-09-22 09:43:25 Re: Constraint exclusion on UNION ALL subqueries with WHERE conditions