Обсуждение: Release Notes Overview
My suggested edit of the Overview section of the Release Notes. The emphasis is on user-noticeable features, so some of the major internal changes are lower down the list. Some items have been removed or placed below the performance features. New data types for SQL/XML, enum and uuid types Updateable Cursors, plus support in PL/pgSQL. PostgreSQL now supports all major items of Core SQL:2003 compatibility. Full text Search is now a built-in feature, so .... is easier/better Asynchronous Commit allows some transactions to commit faster than others, offering a trade-off between performance and durability for specific transaction types only Database Size reductions both per-row and per-field Additional security features: GSSAPI/SSPI and easier to implement security-definer functions using per function SET parameters New ORDER BY ... NULLS FIRST/LAST option and matching support for indexes allows easier migration of applications from other RDBMS Better scalability and more consistent response times come from systematic removal of internal contention points within the server Performance improvements in many important workloads - update-intensive workloads now avoid index inserts via a new internal mechanism known as HOT, plus multiple concurrent auto-vacuum processes maintain the database more consistently - initial data loads now avoid writing WAL, plus all data loads use less CPU than previously - large table scans by optimising cache usage and allowing multiple synchronous scans to reuse the same data, avoiding I/O - short read-only transactions give reduced costs and higher scalability using lazy transactionid assignment Tracking of internal activity has many additional features, improving your ability to design, manage and maintain the database Self-adjusting background writer helps write-intensive workloads -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
"Simon Riggs" <simon@2ndquadrant.com> writes: > Asynchronous Commit allows some transactions to commit faster than > others, offering a trade-off between performance and durability for > specific transaction types only A lot of users will be confused about what asynchronous commit does. I think it's important to be consistently precise when describing it. It doesn't allow commits to be any faster, what it does is "allow clients to start a new transaction and continue working without waiting for their previous commit to complete". Saying something like "This allows high volumes of short transactions such as typical web sites to run more efficiently and with fewer connections" might also help clarify the use case it helps. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Fri, 2007-10-05 at 11:24 +0100, Gregory Stark wrote: > "Simon Riggs" <simon@2ndquadrant.com> writes: > > > Asynchronous Commit allows some transactions to commit faster than > > others, offering a trade-off between performance and durability for > > specific transaction types only > > A lot of users will be confused about what asynchronous commit does. I think > it's important to be consistently precise when describing it. > > It doesn't allow commits to be any faster, what it does is "allow clients to > start a new transaction and continue working without waiting for their > previous commit to complete". Saying something like "This allows high volumes > of short transactions such as typical web sites to run more efficiently and > with fewer connections" might also help clarify the use case it helps. The general shape of the overview was what I was looking at. I agree with your specific comment. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
Gregory Stark wrote: > > "Simon Riggs" <simon@2ndquadrant.com> writes: > > > Asynchronous Commit allows some transactions to commit faster than > > others, offering a trade-off between performance and durability for > > specific transaction types only > > A lot of users will be confused about what asynchronous commit does. I think > it's important to be consistently precise when describing it. > > It doesn't allow commits to be any faster, what it does is "allow clients to > start a new transaction and continue working without waiting for their > previous commit to complete". Saying something like "This allows high volumes > of short transactions such as typical web sites to run more efficiently and > with fewer connections" might also help clarify the use case it helps. Well, logically the commit does happen faster in that your transaction and others see the commit. It is just durability that is delayed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +