From: | Peter T Mount <peter(at)retep(dot)org(dot)uk> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | gjerde(at)icebox(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Problems with >2GB tables on Linux 2.0 |
Date: | 1999-02-08 19:19:19 |
Message-ID: | Pine.LNX.4.04.9902081917270.19320-100000@maidast.retep.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 8 Feb 1999, Bruce Momjian wrote:
> > Not sure. My original choice was to subtract 1 from the calculated
> > maximum, which meant it would split just before the 2Gb limit.
> >
> > However, running with the value set at the lower value:
> >
> > 1998585856 Feb 8 02:25 /opt/db/base/test/smallcat
> > 599007232 Feb 8 03:21 /opt/db/base/test/smallcat.1
> >
> > Total 26653000 rows loaded
> >
> > Would anyone really notice the lower value?
> >
> > Perhaps we could make this another compile time setting, like the block
> > size?
>
> I guess all I am saying is I prefer the max-1 value. Seems more
> logical. Could be set in config.h.in, though.
That's what I thought when I posted the small patch. However, there now
seems to be a consensus for a smaller segment size. Toms (for some reason
I called him John yesterday?) idea of 200000 (1.6Gb) works, and I know it
works ok on smaller segment sizes (I used 2Mb segments to see that it
worked past the second segment).
Peter
--
Peter T Mount peter(at)retep(dot)org(dot)uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-02-08 19:31:12 | Re: [HACKERS] Optimizer problems |
Previous Message | Peter T Mount | 1999-02-08 19:16:57 | Re: [HACKERS] Problems with >2GB tables on Linux 2.0 |