| From: | Brook Milligan <brook(at)trillium(dot)NMSU(dot)Edu> |
|---|---|
| To: | jwieck(at)debis(dot)com |
| Cc: | vadim(at)krs(dot)ru, maillist(at)candle(dot)pha(dot)pa(dot)us, t-ishii(at)sra(dot)co(dot)jp, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Arbitrary tuple size |
| Date: | 1999-07-09 17:02:14 |
| Message-ID: | 199907091702.LAA10746@trillium.nmsu.edu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I don't like _arbitrary_ tuple size.
> I vote for some limit. 32K or 64K, at max.
To have some limit seems reasonable for me (I've also read
the other comments). When dealing with regular tuples, first
Isn't anything other than arbitrary sizes just making us encounter the
same problem later. Clearly, there are real hardware limits, but we
shouldn't build that into the code. It seems to me the solution is to
have arbitrary (e.g., hardware driven) limits, document what is
necessary to support certain operations, and let the fanatics buy
mega-systems if they need to support huge tuples. As long as the code
is optimized for more reasonable situations, there should be no
penalty.
Cheers,
Brook
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 1999-07-09 17:07:04 | Re: [HACKERS] "24" < INT_MIN returns TRUE ??? |
| Previous Message | Jackson, DeJuan | 1999-07-09 17:00:20 | Regression Test fail to run if PLPGSQL in template1 |