Chris Browne <[EMAIL PROTECTED]> writes:
> If the field is immaterial in terms of the size of the table, then it
> won't help materially.
> If you were going to index on it, however, THAT would make it
> significant for indices involving the "genre" column. Fitting more
> tuples into each page is
[EMAIL PROTECTED] ("Announce") writes:
> I KNOW that I am not going to have anywhere near 32,000+ different
> genres in my genre table so why use int4? Would that squeeze a few
> more milliseconds of performance out of a LARGE song table query
> with a genre lookup?
If the field is immaterial in
[EMAIL PROTECTED] ("Announce") writes:
> I KNOW that I am not going to have anywhere near 32,000+ different
> genres in my genre table so why use int4? Would that squeeze a few
> more milliseconds of performance out of a LARGE song table query
> with a genre lookup?
By the way, I see a lot of que
On Mon, 2005-26-09 at 12:54 -0500, Announce wrote:
> Is there an performance benefit to using int2 (instead of int4) in cases
> where i know i will be well within its numeric range?
int2 uses slightly less storage space (2 bytes rather than 4). Depending
on alignment and padding requirements, as w
On Mon, Sep 26, 2005 at 12:54:05PM -0500, Announce wrote:
> Is there an performance benefit to using int2 (instead of int4) in cases
> where i know i will be well within its numeric range? I want to conserve
> storage space and gain speed anywhere i can, but i know some apps simply end
> up casting
Is there an performance benefit to using int2 (instead of int4) in cases
where i know i will be well within its numeric range? I want to conserve
storage space and gain speed anywhere i can, but i know some apps simply end
up casting 2byte data to 4byte (like Java int/short).
These int2 values wil
