From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: fixed-length row |
Date: | 2004-01-15 15:54:55 |
Message-ID: | 22409.1074182095@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> writes:
> The MySQL manual recommends that we create a "fixed-length row" if
> possible, for speed (especially scanning speed).
> Is there a similar recommendation in PostgreSQL?
No. There are some marginal optimizations that take place if your
columns are fixed-width and not null, but I wouldn't suggest contorting
your database design to enable them to occur.
In particular, people who have taken this bait generally think that
it's a good idea to substitute char(n) for varchar(n). That is almost
inevitably a pessimization, because the extra I/O time for all those
padding blanks will surely swamp the few CPU cycles saved by using
precalculated field offsets. (Not to mention that char(n) is not really
fixed-width anyway, in Postgres or any other implementation that
supports variable-length character encodings.)
I'd be willing to speculate that the MySQL manual's advice is bad
even for MySQL, but I haven't benchmarked the case there.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-01-15 15:56:28 | Re: Returning large select results from stored procedures |
Previous Message | Jan Wieck | 2004-01-15 15:47:56 | Re: Oracle -> Postgres live translation? |