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