From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Daniel Westermann <Daniel(dot)Westermann(at)lcsystems(dot)ch>, "'pgsql-performance(at)postgresql(dot)org'" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: FW: performance issue with a 2.5gb joinded table |
Date: | 2013-01-04 20:40:51 |
Message-ID: | 24975.1357332051@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> One difference is that numerics are stored more tightly packed on
> Oracle. Which is particularly good for Oracle as they don't have other
> numeric data types than number. On PostgreSQL, you'll want to use int4
> for ID-fields, where possible. An int4 always takes up 4 bytes, while a
> numeric holding an integer value in the same range is typically 5-9 bytes.
Replacing those numeric(8) and numeric(16) fields with int4 and int8
would be greatly beneficial to comparison and hashing performance,
not just table size. I'm a bit surprised that EDB's porting tools
evidently don't do this automatically (I infer from the reference to
PPAS that the OP is using EDB ...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | nobody nowhere | 2013-01-04 21:07:50 | Re[4]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database |
Previous Message | Claudio Freire | 2013-01-04 19:04:00 | Re: Re[2]: [PERFORM] SMP on a heavy loaded database |