Re: [HACKERS] Problems with >2GB tables on Linux 2.0
От | Peter T Mount |
---|---|
Тема | Re: [HACKERS] Problems with >2GB tables on Linux 2.0 |
Дата | |
Msg-id | Pine.LNX.4.04.9902092052550.19320-100000@maidast.retep.org.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] Problems with >2GB tables on Linux 2.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, 8 Feb 1999, Tom Lane wrote: > Peter T Mount wrote: > >> How about dropping the suffix, so you would have: > >> .../data/2/tablename > >> Doing that doesn't mean having to increase the filename buffer size, just > >> the format and arg order (from %s.%d to %d/%s). > > I thought of that also, but concluded it was a bad idea, because it > means you cannot symlink several of the /n subdirectories to the same > place. It also seems just plain risky/errorprone to have different > files named the same thing... That's true. [snip] > >> I'd think we could add a test when the new segment is created for the > >> symlink/directory. If it doesn't exist, then create it. > > Absolutely, the system would need to auto-create a /n subdirectory if > one didn't already exist. > > > I'd suggest making the max file size 1 Gig default, configurable > > someplace, and solving the data distribution as a separate effort. > > We might actually be saying the same thing, if by that remark you > mean that we can come back later and write "real" data distribution > management tools. I'm just pointing out that given a configurable > max file size we can have a primitive facility almost for free. We are saying the same thing. To implement having the %d/%s.%d format we'd need to just add 11 bytes to the temporary buffer (keeping the same capacity as the cuurent code). Peter -- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf
В списке pgsql-hackers по дате отправления: