1berry/MariaDB-server
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

VACUUM fixup in PostgreSQL info.

Browse Source
This commit is contained in:
arjen@co3064164-a.bitbike.com 2002-02-18 16:49:09 +10:00
parent 531ae581fb
commit 68cbe4d708
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
Docs/manual.texi
View File

@ -4815,13 +4815,13 @@ existing programs than PostgreSQL. @xref{Contrib}.
@item @item
MySQL Server works on 24/7 heavy duty systems. In most circumstances MySQL Server works on 24/7 heavy duty systems. In most circumstances
you never have to run any cleanups on MySQL Server. PostgreSQL doesn't you never have to run any cleanups on MySQL Server. PostgreSQL doesn't
yet support 24/7 systems because you have to run @code{VACUUM()} yet support 24/7 systems because you have to run @code{VACUUM}
once in a while to reclaim space from @code{UPDATE} and @code{DELETE} once in a while to reclaim space from @code{UPDATE} and @code{DELETE}
commands and to perform statistics analyses that are critical to get commands and to perform statistics analyses that are critical to get
good performance with PostgreSQL. @code{VACUUM()} is also needed after good performance with PostgreSQL. @code{VACUUM} is also needed after
adding a lot of new rows to a table. On a busy system with lots of changes, adding a lot of new rows to a table. On a busy system with lots of changes,
@code{VACUUM()} must be run very frequently, in the worst cases even @code{VACUUM} must be run very frequently, in the worst cases even
many times a day. During the @code{VACUUM()} run, which may take hours many times a day. During the @code{VACUUM} run, which may take hours
if the database is big, the database is from a production standpoint, if the database is big, the database is from a production standpoint,
practically dead. Please note: In PostgreSQL version 7.2, basic vacuuming practically dead. Please note: In PostgreSQL version 7.2, basic vacuuming
no longer locks tables, thus allowing normal user access during the vacuum. no longer locks tables, thus allowing normal user access during the vacuum.
@ -5023,7 +5023,7 @@ Drawbacks with PostgreSQL compared to MySQL Server:
@itemize @bullet @itemize @bullet
@item @item
@code{VACUUM()} makes PostgreSQL hard to use in a 24/7 environment. @code{VACUUM} makes PostgreSQL hard to use in a 24/7 environment.
@item @item
Only transactional tables. Only transactional tables.
@ -5064,10 +5064,10 @@ the @code{--fast} run shows how the server would do if the application
developer would use extensions in the server to make his application run developer would use extensions in the server to make his application run
faster. faster.
When running with PostgreSQL and @code{--fast} we do a @code{VACUUM()} When running with PostgreSQL and @code{--fast} we do a @code{VACUUM}
after every major table @code{UPDATE} and @code{DROP TABLE} to make the after every major table @code{UPDATE} and @code{DROP TABLE} to make the
database in perfect shape for the following @code{SELECT}s. The time for database in perfect shape for the following @code{SELECT}s. The time for
@code{VACUUM()} is measured separately. @code{VACUUM} is measured separately.
When running with PostgreSQL 7.1.1 we could, however, not run with When running with PostgreSQL 7.1.1 we could, however, not run with
@code{--fast} because during the @code{INSERT} test, the postmaster (the @code{--fast} because during the @code{INSERT} test, the postmaster (the
@ -5135,12 +5135,12 @@ this as a ``standard'' benchmark tool is to stretch the truth a long way.
@item @item
Great Bridge admitted that they had optimised the PostgreSQL database Great Bridge admitted that they had optimised the PostgreSQL database
(with @code{VACUUM()} before the test) and tuned the startup for the tests, (with @code{VACUUM} before the test) and tuned the startup for the tests,
something they hadn't done for any of the other databases involved. To something they hadn't done for any of the other databases involved. To
say ``This process optimises indexes and frees up disk space a bit. The say ``This process optimises indexes and frees up disk space a bit. The
optimised indexes boost performance by some margin.'' Our benchmarks optimised indexes boost performance by some margin.'' Our benchmarks
clearly indicate that the difference in running a lot of selects on a clearly indicate that the difference in running a lot of selects on a
database with and without @code{VACUUM()} can easily differ by a factor database with and without @code{VACUUM} can easily differ by a factor
of ten. of ten.
@item @item
@ -5149,7 +5149,7 @@ mentions that the test does ``selections, simple joins, projections,
aggregates, one-tuple updates, and bulk updates''. aggregates, one-tuple updates, and bulk updates''.
PostgreSQL is good at doing @code{SELECT}s and @code{JOIN}s (especially PostgreSQL is good at doing @code{SELECT}s and @code{JOIN}s (especially
after a @code{VACUUM()}), but doesn't perform as well on @code{INSERT}s or after a @code{VACUUM}, but doesn't perform as well on @code{INSERT}s or
@code{UPDATE}s. The benchmarks seem to indicate that only @code{SELECT}s @code{UPDATE}s. The benchmarks seem to indicate that only @code{SELECT}s
were done (or very few updates). This could easily explain they good results were done (or very few updates). This could easily explain they good results
for PostgreSQL in this test. The bad results for MySQL will be obvious a for PostgreSQL in this test. The bad results for MySQL will be obvious a