From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jan Wieck <wieck(at)debis(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] LONG |
Date: | 1999-12-11 19:39:05 |
Message-ID: | 3852A859.DA32BAEF@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
>
> But I don't really see why this would be either easier to do or
> more reliable than storing multiple segments of a tuple in the
> primary relation itself. And I don't much care for
> institutionalizing a hack like a special "LONG" datatype.
AFAIK the "hack" is similar to what Oracle does.
At least this is my impression from some descriptions, and it also
seems reasonable thing to do in general as we dont want to read in
500K tuples (and then sort them) just to join on int fields and filter
out on boolean and count(n) < 3.
The description referred above is about Oracle's habit to return LONG*
fields as open file descriptions ready for reading when doing FETCH 1
and as already read-in "strings" when fetching more than 1 tuple.
--------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 1999-12-11 19:48:34 | Re: [HACKERS] LONG |
Previous Message | Hannu Krosing | 1999-12-11 19:29:15 | Re: [HACKERS] Last thoughts about LONG |