Fabien COELHO wrote:


> 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

> 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

Á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:

Reply via email to