Benchmarks has shown that aligning the buffer descriptor array to cache lines is important for scalability; especially on bigger, multi-socket, machines. Currently the array sometimes already happens to be aligned by happenstance, depending how large previous shared memory allocations were. That can lead to wildly varying performance results after minor configuration changes. In addition to aligning the start of descriptor array, also force the size of individual descriptors to be of a common cache line size (64 bytes). That happens to already be the case on 64bit platforms, but this way we can change the struct BufferDesc more easily. As the alignment primarily matters in highly concurrent workloads which probably all are 64bit these days, and the space wastage of element alignment would be a bit more noticeable on 32bit systems, we don't force the stride to be cacheline sized on 32bit platforms for now. If somebody does actual performance testing, we can reevaluate that decision by changing the definition of BUFFERDESC_PADDED_SIZE. Discussion: 20140202151319.GD32123@awork2.anarazel.de Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter Geoghegan. |
||
---|---|---|
.. | ||
adminpack | ||
auth_delay | ||
auto_explain | ||
btree_gin | ||
btree_gist | ||
chkpass | ||
citext | ||
cube | ||
dblink | ||
dict_int | ||
dict_xsyn | ||
earthdistance | ||
file_fdw | ||
fuzzystrmatch | ||
hstore | ||
intagg | ||
intarray | ||
isn | ||
lo | ||
ltree | ||
oid2name | ||
pageinspect | ||
passwordcheck | ||
pg_archivecleanup | ||
pg_buffercache | ||
pg_freespacemap | ||
pg_prewarm | ||
pg_standby | ||
pg_stat_statements | ||
pg_test_fsync | ||
pg_test_timing | ||
pg_trgm | ||
pg_upgrade | ||
pg_upgrade_support | ||
pg_xlogdump | ||
pgbench | ||
pgcrypto | ||
pgrowlocks | ||
pgstattuple | ||
postgres_fdw | ||
seg | ||
sepgsql | ||
spi | ||
sslinfo | ||
start-scripts | ||
tablefunc | ||
tcn | ||
test_decoding | ||
tsearch2 | ||
unaccent | ||
uuid-ossp | ||
vacuumlo | ||
xml2 | ||
Makefile | ||
README | ||
contrib-global.mk |
README
The PostgreSQL contrib tree --------------------------- This subtree contains porting tools, analysis utilities, and plug-in features that are not part of the core PostgreSQL system, mainly because they address a limited audience or are too experimental to be part of the main source tree. This does not preclude their usefulness. User documentation for each module appears in the main SGML documentation. When building from the source distribution, these modules are not built automatically, unless you build the "world" target. You can also build and install them all by running "make all" and "make install" in this directory; or to build and install just one selected module, do the same in that module's subdirectory. Some directories supply new user-defined functions, operators, or types. To make use of one of these modules, after you have installed the code you need to register the new SQL objects in the database system by executing a CREATE EXTENSION command. In a fresh database, you can simply do CREATE EXTENSION module_name; See the PostgreSQL documentation for more information about this procedure.