Tom Lane wrote:
[ redirecting to -hackers for wider comment ]

Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
LET_OS_MANAGE_FILESIZE is good way. I think one problem of this option I fixed. It is size of offset. I went thru the code and did not see any other problem there. However, how you mentioned it need more testing. I going to take server with large disk array and I will test it.

I would like to add --enable-largefile switch to configure file to enable access to wide group of users. What you think about it?

Yeah, I was going to suggest the same thing --- but not with that switch
name.  We already use enable/disable-largefile to control whether 64-bit
file access is built at all (this mostly affects pg_dump at the moment).

I think the clearest way might be to flip the sense of the variable.
I never found "LET_OS_MANAGE_FILESIZE" to be a good name anyway.  I'd
suggest "USE_SEGMENTED_FILES", which defaults to "on", and you can
turn it off via --disable-segmented-files if configure confirms your
OS has largefile support (thus you could not specify both this and

There is latest version of nonsegment support patch. I changed LET_OS_MANAGE_FILESIZE to USE_SEGMENTED_FILES and I added -disable-segmented-files switch to configure. I kept tuplestore behavior and it still split file in both mode.

I also little bit cleanup some other datatypes (e.g int->mode_t).
Autoconf and autoheader must be run after patch application.

I tested it with 9GB table and both mode works fine.

Please, let me know your comments.


Attachment: nonseg.patch.gz
Description: GNU Zip compressed data

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to