Fabien COELHO wrote: Hi,
> Note that I was more asking about the desirability of the feature, > the implementation is another, although also relevant, issue. To me > it is really desirable given the potential performance impact, but > maybe we should not care about 10%? 10% performance improvement sounds good, no doubt. What will happen to performance for people with the same block size? I mean, if you run a comparison of current HEAD vs. patched with identical BLCKSZ, is there a decrease in performance? I expect there will be some, although I'm not sure to what extent. People who pg_upgrade for example will be stuck with whatever blcksz they had on the original installation and so will be unable to benefit from this improvement. I admit I'm not sure where's the breakeven point, i.e. what's the loss we're willing to tolerate. It might be pretty small. > About your point: if we really have to do without dynamic stack > allocation (C99 is only 15, not ripe for adult use yet, maybe when > it turns 18 or 21, depending on the state:-), a possible way around > would be to allocate a larger area with some MAX_BLCKSZ with a ifdef > for compilers that really would not support dynamic stack > allocation. Moreover, it might be possible to hide it more or less > cleanly in a macro. Maybe we could try to use dynamic stack allocation on compilers that support it, and use your MAX_BLCKSZ idea on the rest. Of course, finding all problematic code sites might prove difficult. I pointed out the one case I'm familiar with because of working with similar code recently. > I had to put "-pedantic -Werror" to manage to > get an error on dynamic stack allocation with "gcc -std=c89". Yeah, I guess in practice it will work everywhere except very old dinosaurs and Windows. But see a thread elsewhere about supporting VAXen; we don't appear to be prepared to drop support for dinosaurs just yet. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers