On 9/26/13 12:00 PM, Robert Haas wrote:
More generally, I fear we really opened a bag of worms with this relation fork stuff. Every time I turn around I run into a problem that could be solved by adding another relation fork. I'm not terribly sure that it was a good idea to go that way to begin with, because we've got customers who are unhappy about 3 files/heap due to inode consumption and slow directory lookups. I think we would have been smarter to devise a strategy for storing the fsm and vm pages within the main fork in some fashion, and I tend to think that's the right solution here as well. Of course, it may be hopeless to put the worms back in the can at this point, and surely these indexes will be lightly used compared to heaps, so it's not incrementally exacerbating the problems all that much. But I still feel uneasy about widening use of that mechanism.
Why would we add additional code complexity when forks do the trick? That seems like a step backwards, not forward. If the only complaint about forks is directory traversal why wouldn't we go with the well established practice of using multiple directories instead of glomming everything into one place? -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
