On Fri, Jul 17, 2009 at 10:40 PM, Kevin Grittner<kevin.gritt...@wicourts.gov> wrote: > Laurent Laborde <kerdez...@gmail.com> wrote: > >> But... on which version are you planning to do that ? > > The patch, if there's consensus that it's a good idea, would be for > 8.5. Since it is new functionality, there wouldn't be a back-port to > prior releases. Of course, I wouldn't be starting to work on such a > patch until after our current code commit phase, which ends August > 15th.
Sure, no problem. >> We stay on Pg 8.3 until the slony developpers find a better upgrade >> solution. >> >> The proposed solution sound really good to me. >> But, for now, if i could have a simple patch for 8.3 (eg: changing a >> #define in the source code), i'd be very happy :) >> >> Is it ok to just change TOAST_TUPLES_PER_PAGE ? > > The thing that worries me about that is that it would tend to force > more data to be stored out-of-line, which might *increase* your I/O; > since the whole point of this exercise is to try to *decrease* it, > that seems pretty iffy. However, once we get to the end of code > commit, I might be able to give you a little one-off patch that would > be more aggressive about compression without affecting out-of-line > storage. Hard-coded, like what you're talking about, but with a > little more finesse. Awesome ! Yes, i understand the problem. What about SET STORAGE MAIN then ? To prevent out-of-line storage ? We use PLAIN on some specific column (i don't know why, it was here before i join overblog) And the default extended storage for all other columns. Thank you :) -- Laurent Laborde Sysadmin @ http://www.over-blog.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
