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
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 |