| Lists: | pgsql-hackerspgsql-performance |
|---|
| From: | Daniel Kalchev <daniel(at)digsys(dot)bg> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dann Corbit <DCorbit(at)connx(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Terrible performance on wide selects |
| Date: | 2003-01-23 10:44:04 |
| Message-ID: | 200301231044.h0NAi8Y21333@dcave.digsys.bg |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-performance |
>>>Hannu Krosing said:
> Tom Lane kirjutas N, 23.01.2003 kell 02:04:
> > We already do cache column offsets when they are fixed. The code that's
> > the problem executes when there's a variable-width column in the table
> > --- which means that all columns to its right are not at fixed offsets,
> > and have to be scanned for separately in each tuple, AFAICS.
>
> Not only varlen columns, but also NULL columns forbid knowing the
> offsets beforehand.
Does this mean, that constructing tables where fixed length fields are
'before' variable lenght fields and 'possibly null' fields might increase
performance?
Daniel
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Daniel Kalchev <daniel(at)digsys(dot)bg> |
| Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, Dann Corbit <DCorbit(at)connx(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Terrible performance on wide selects |
| Date: | 2003-01-23 14:50:02 |
| Message-ID: | 25738.1043333402@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-performance |
Daniel Kalchev <daniel(at)digsys(dot)bg> writes:
> Does this mean, that constructing tables where fixed length fields are
> 'before' variable lenght fields and 'possibly null' fields might increase
> performance?
There'd have to be no nulls, period, to get any useful performance
difference --- but yes, in theory putting fixed-length columns before
variable-length ones is a win.
I wouldn't bother going out to rearrange your schemas though ... at
least not before you do some tests to prove that it's worthwhile.
regards, tom lane
| From: | Curt Sampson <cjs(at)cynic(dot)net> |
|---|---|
| To: | Daniel Kalchev <daniel(at)digsys(dot)bg> |
| Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dann Corbit <DCorbit(at)connx(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PERFORM] Terrible performance on wide selects |
| Date: | 2003-01-23 15:50:27 |
| Message-ID: | Pine.NEB.4.51.0301240048580.547@angelic.cynic.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers pgsql-performance |
On Thu, 23 Jan 2003, Daniel Kalchev wrote:
> Does this mean, that constructing tables where fixed length fields are
> 'before' variable lenght fields and 'possibly null' fields might increase
> performance?
This, I believe, is why DB2 always puts (in physical storage) all of the
fixed-length fields before the variable-length fields.
cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC