Revision 12622
Added by Aaron Marcuse-Kubitza almost 11 years ago
trunk/web/links/index.htm | ||
---|---|---|
680 | 680 |
</DL><p> |
681 | 681 |
<DT><a name="PostgreSQL" href="#PostgreSQL"><H3 ADD_DATE="1333386475">PostgreSQL</H3></a> |
682 | 682 |
<DL><p> |
683 |
<DT><a name="* TIDs" href="#* TIDs"><H3 ADD_DATE="1394183336">* TIDs</H3></a> |
|
684 |
<DL><p> |
|
685 |
<DT><A HREF="http://postgresql.1045698.n5.nabble.com/Using-ctid-column-changes-plan-drastically-td5717711.html" name="http://postgresql.1045698.n5.nabble.com/Using-ctid-column-changes-plan-drastically-td5717711.html" ADD_DATE="1394185828" ICON_URI="http://postgresql.1045698.n5.nabble.com/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://postgresql.1045698.n5.nabble.com/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL - performance - Using ctid column changes plan drastically</A><a name="PostgreSQL - performance - Using ctid column changes plan drastically" href="#PostgreSQL - performance - Using ctid column changes plan drastically" style="margin-left: 0.5em;">¶</a> |
|
686 |
<DD>page's own description: Using ctid column changes plan drastically. Hi, I was testing a query to delete duplicates to see how well using ctid works if the table doesn't have a unique identifier available. The table... |
|
687 |
|
|
688 |
"Joins on tid columns just aren't supported very well at the moment. [...] There are gotchas if any of the rows receive concurrent updates." (Tom Lane) |
|
689 |
|
|
690 |
"type tid doesn't have any hash support" (Tom Lane) |
|
691 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/ddl-system-columns.html" name="http://www.postgresql.org/docs/9.3/static/ddl-system-columns.html" ADD_DATE="1394185064" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: System Columns</A><a name="PostgreSQL: Documentation: 9.3: System Columns" href="#PostgreSQL: Documentation: 9.3: System Columns" style="margin-left: 0.5em;">¶</a> |
|
692 |
<DD>"ctid |
|
693 |
The physical location of the row version within its table. Note that although the ctid can be used to locate the row version very quickly, a row's ctid will change if it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier [unless your DB is select-optimized and rarely updated]. The OID, or even better a user-defined serial number, should be used to identify logical rows." |
|
694 |
<DT><A HREF="http://www.postgresql.org/message-id/200206031717.g53HHLs03112@saturn.janwieck.net" name="http://www.postgresql.org/message-id/200206031717.g53HHLs03112@saturn.janwieck.net" ADD_DATE="1394183279" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>Re: tid scan - is it ever used?</A><a name="Re: tid scan - is it ever used?" href="#Re: tid scan - is it ever used?" style="margin-left: 0.5em;">¶</a> |
|
695 |
<DD>" |
|
696 |
Currently it is the fastest possible access to a single row. |
|
697 |
So an application that selects data and wants to update rows |
|
698 |
is optimized for PostgreSQL if it knows about that fact and |
|
699 |
qualifies the updates by ctid. |
|
700 |
" |
|
701 |
<DT><A HREF="http://www.postgresql.org/message-id/1031147457.3339.12.camel@taru.tm.ee" name="http://www.postgresql.org/message-id/1031147457.3339.12.camel@taru.tm.ee" ADD_DATE="1394183324" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>Re: What is Tid Scan</A><a name="Re: What is Tid Scan" href="#Re: What is Tid Scan" style="margin-left: 0.5em;">¶</a> |
|
702 |
<DD>"It is scanning table by TupleID's. A tuple id is a 6-byte entity which |
|
703 |
consists of 4-byte page number and 2-byte tuple index inside page. |
|
704 |
|
|
705 |
So if you know the TID you can directly get the corresponding tuple." |
|
706 |
<DT><A HREF="http://blog.2ndquadrant.com/using_the_postgresql_system_co/" name="http://blog.2ndquadrant.com/using_the_postgresql_system_co/" ADD_DATE="1394186108" ICON_URI="http://blog.2ndquadrant.com/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://blog.2ndquadrant.com/favicon.ico" style="margin-right: 0.5em;"/>Using the PostgreSQL System Columns | 2ndQuadrant</A><a name="Using the PostgreSQL System Columns | 2ndQuadrant" href="#Using the PostgreSQL System Columns | 2ndQuadrant" style="margin-left: 0.5em;">¶</a> |
|
707 |
<DD>"One thing you can use these for is finding duplicate data in a table. Let’s say you’re trying to add a unique constraint, but one row in the table is duplicated 3 times, which blocks the unique index from being created. When rows are identical in every column, you can’t write any simple SELECT statement to uniquely identify them. That means deleting all of them but one copy requires some annoying and fragile SQL code, combining DELETE with LIMIT and/or OFFSET–which is always scary. If you use the ctid instead, the implementation will be PostgreSQL specific, but it will also be faster and cleaner. See Deleting Duplicate Records in a Table for an example of how that can be done." |
|
708 |
</DL><p> |
|
683 | 709 |
<DT><a name="disk space" href="#disk space"><H3 ADD_DATE="1340661986">disk space</H3></a> |
684 | 710 |
<DL><p> |
685 | 711 |
<DT><a name="quotas" href="#quotas"><H3 ADD_DATE="1373521860">quotas</H3></a> |
... | ... | |
695 | 721 |
</DL><p> |
696 | 722 |
<DT><A HREF="http://dba.stackexchange.com/questions/3491/postgresql-disk-space-not-released-after-truncate" name="http://dba.stackexchange.com/questions/3491/postgresql-disk-space-not-released-after-truncate" ADD_DATE="1340661221" ICON_URI="http://cdn.sstatic.net/dba/img/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://cdn.sstatic.net/dba/img/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Disk space not released after TRUNCATE - Database Administrators</A><a name="PostgreSQL: Disk space not released after TRUNCATE - Database Administrators" href="#PostgreSQL: Disk space not released after TRUNCATE - Database Administrators" style="margin-left: 0.5em;">¶</a> |
697 | 723 |
<DT><A HREF="https://issues.apache.org/jira/browse/JENA-28" name="https://issues.apache.org/jira/browse/JENA-28" ADD_DATE="1340661975" ICON_URI="https://issues.apache.org/jira/s/en_UKd9dgiy/731/4/_/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="https://issues.apache.org/jira/s/en_UKd9dgiy/731/4/_/favicon.ico" style="margin-right: 0.5em;"/>[#JENA-28] Drop Temporary Tables in Postgres (PATCH) - ASF JIRA</A><a name="[#JENA-28] Drop Temporary Tables in Postgres (PATCH) - ASF JIRA" href="#[#JENA-28] Drop Temporary Tables in Postgres (PATCH) - ASF JIRA" style="margin-left: 0.5em;">¶</a> |
698 |
<DT><A HREF="http://wiki.postgresql.org/wiki/VACUUM_FULL" name="http://wiki.postgresql.org/wiki/VACUUM_FULL" ADD_DATE="1340665068" LAST_CHARSET="UTF-8"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>VACUUM FULL - PostgreSQL wiki</A><a name="VACUUM FULL - PostgreSQL wiki" href="#VACUUM FULL - PostgreSQL wiki" style="margin-left: 0.5em;">¶</a> |
|
699 | 724 |
<DT><A HREF="http://www.postgresql.org/docs/8.3/static/sql-cluster.html" name="http://www.postgresql.org/docs/8.3/static/sql-cluster.html" ADD_DATE="1340665221" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 8.3: CLUSTER</A><a name="PostgreSQL: Documentation: 8.3: CLUSTER" href="#PostgreSQL: Documentation: 8.3: CLUSTER" style="margin-left: 0.5em;">¶</a> |
700 | 725 |
<DT><A HREF="http://archives.postgresql.org/pgsql-sql/2006-09/msg00142.php" name="http://archives.postgresql.org/pgsql-sql/2006-09/msg00142.php" ADD_DATE="1340668156" LAST_CHARSET="UTF-8"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>Re: ERROR: could not write block 196261 of temporary file: No space left</A><a name="Re: ERROR: could not write block 196261 of temporary file: No space left" href="#Re: ERROR: could not write block 196261 of temporary file: No space left" style="margin-left: 0.5em;">¶</a> |
701 | 726 |
<DT><A HREF="http://postgresql-in.blogspot.com/2008/04/postgresql-in-place-update.html" name="http://postgresql-in.blogspot.com/2008/04/postgresql-in-place-update.html" ADD_DATE="1340673360" ICON_URI="http://postgresql-in.blogspot.com/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://postgresql-in.blogspot.com/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: PostgreSQL: In place UPDATE</A><a name="PostgreSQL: PostgreSQL: In place UPDATE" href="#PostgreSQL: PostgreSQL: In place UPDATE" style="margin-left: 0.5em;">¶</a> |
... | ... | |
730 | 755 |
if you try to disable a foreign key constraint's trigger, you will get an error, even if it is marked NOT VALID: |
731 | 756 |
"ERROR: permission denied: "RI_ConstraintTrigger_..." is a system trigger |
732 | 757 |
SQL state: 42501" |
758 |
|
|
759 |
"To force an immediate rewrite of the table, you can use VACUUM FULL, CLUSTER or one of the forms of ALTER TABLE that forces a rewrite. This results in no semantically-visible change in the table, but gets rid of no-longer-useful data." |
|
733 | 760 |
<DT><A HREF="http://www.postgresql.org/docs/9.1/static/sql-analyze.html" name="http://www.postgresql.org/docs/9.1/static/sql-analyze.html" ADD_DATE="1377904843" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.1: ANALYZE</A><a name="PostgreSQL: Documentation: 9.1: ANALYZE" href="#PostgreSQL: Documentation: 9.1: ANALYZE" style="margin-left: 0.5em;">¶</a> |
734 | 761 |
<DD>"the autovacuum daemon (see Section 23.1.5) takes care of automatic analyzing of tables when they are first loaded with data, and as they change throughout regular operation" |
735 | 762 |
<DT><A HREF="http://www.postgresql.org/docs/9.1/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW" name="http://www.postgresql.org/docs/9.1/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW" ADD_DATE="1379915256" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.1: Basic Statements: 39.5.4. Executing Dynamic Commands</A><a name="PostgreSQL: Documentation: 9.1: Basic Statements: 39.5.4. Executing Dynamic Commands" href="#PostgreSQL: Documentation: 9.1: Basic Statements: 39.5.4. Executing Dynamic Commands" style="margin-left: 0.5em;">¶</a> |
... | ... | |
867 | 894 |
<DD>"For some types of errors, the server reports the name of a database object (a table, table column, data type, or constraint) associated with the error; for example, the name of the unique constraint that caused a unique_violation error. Such names are supplied in separate fields of the error report message so that applications need not try to extract them from the possibly-localized human-readable text of the message. As of PostgreSQL 9.3, complete coverage for this feature exists only for errors in SQLSTATE class 23 (integrity constraint violation), but this is likely to be expanded in future." |
868 | 895 |
this is especially useful for error parsing in column-based import [wiki.vegpath.org/Column-based_import] (and may even have been motivated by it!) |
869 | 896 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/app-psql.html#APP-PSQL-PATTERNS" name="http://www.postgresql.org/docs/9.3/static/app-psql.html#APP-PSQL-PATTERNS" ADD_DATE="1392338475" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: psql</A><a name="PostgreSQL: Documentation: 9.3: psql" href="#PostgreSQL: Documentation: 9.3: psql" style="margin-left: 0.5em;">¶</a> |
897 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/runtime-config-query.html" name="http://www.postgresql.org/docs/9.3/static/runtime-config-query.html" ADD_DATE="1394182959" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: Query Planning ****</A><a name="PostgreSQL: Documentation: 9.3: Query Planning ****" href="#PostgreSQL: Documentation: 9.3: Query Planning ****" style="margin-left: 0.5em;">¶</a> |
|
898 |
<DD>- |
|
899 |
**** "join_collapse_limit (integer) |
|
900 |
|
|
901 |
The planner will rewrite explicit JOIN constructs (except FULL JOINs) into lists of FROM items whenever a list of no more than this many items would result. Smaller values reduce planning time but might yield inferior query plans." |
|
902 |
you definitely want to turn this *off* in all cases! joins are written in a particular order for a reason (because the programmer knows which indexes are available and therefore which order is correct). the query planner is not smarter than the programmer! |
|
870 | 903 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST" name="http://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST" ADD_DATE="1394165454" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: Resource Consumption: 18.4.4. Cost-based Vacuum Delay</A><a name="PostgreSQL: Documentation: 9.3: Resource Consumption: 18.4.4. Cost-based Vacuum Delay" href="#PostgreSQL: Documentation: 9.3: Resource Consumption: 18.4.4. Cost-based Vacuum Delay" style="margin-left: 0.5em;">¶</a> |
871 | 904 |
<DD>"During the execution of VACUUM and ANALYZE commands, the system maintains an internal counter that keeps track of the estimated cost of the various I/O operations that are performed. When the accumulated cost reaches a limit (specified by vacuum_cost_limit), the process performing the operation will sleep for a short period of time, as specified by vacuum_cost_delay. Then it will reset the counter and continue execution." |
872 | 905 |
|
873 | 906 |
"This feature is disabled by default for manually issued VACUUM commands." however, *autovacuum*_vacuum_cost_delay is *enabled* by default |
874 | 907 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/ddl-schemas.html" name="http://www.postgresql.org/docs/9.3/static/ddl-schemas.html" ADD_DATE="1393374155" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: Schemas</A><a name="PostgreSQL: Documentation: 9.3: Schemas" href="#PostgreSQL: Documentation: 9.3: Schemas" style="margin-left: 0.5em;">¶</a> |
875 | 908 |
<DD>"pg_catalog is always effectively part of the search path. If it is not named explicitly in the path then it is implicitly searched before searching the path's schemas. This ensures that built-in names will always be findable. However, you can explicitly place pg_catalog at the end of your search path if you prefer to have user-defined names override built-in names." |
909 |
<DT><A HREF="http://www.postgresql.org/docs/9.3/static/ddl-system-columns.html" name="http://www.postgresql.org/docs/9.3/static/ddl-system-columns.html" ADD_DATE="1394185064" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: 9.3: System Columns</A><a name="PostgreSQL: Documentation: 9.3: System Columns" href="#PostgreSQL: Documentation: 9.3: System Columns" style="margin-left: 0.5em;">¶</a> |
|
910 |
<DD>"ctid |
|
911 |
The physical location of the row version within its table. Note that although the ctid can be used to locate the row version very quickly, a row's ctid will change if it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier [unless your DB is select-optimized and rarely updated]. The OID, or even better a user-defined serial number, should be used to identify logical rows." |
|
912 |
|
|
913 |
"tableoid |
|
914 |
The OID of the table containing this row. This column is particularly handy for queries that select from inheritance hierarchies (see Section 5.8), since without it, it's difficult to tell which individual table a row came from. The tableoid can be joined against the oid column of pg_class to obtain the table name." |
|
876 | 915 |
<DT><A HREF="http://www.postgresql.org/docs/8.4/static/logfile-maintenance.html" name="http://www.postgresql.org/docs/8.4/static/logfile-maintenance.html" ADD_DATE="1333386461" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: Manuals: Log File Maintenance</A><a name="PostgreSQL: Documentation: Manuals: Log File Maintenance" href="#PostgreSQL: Documentation: Manuals: Log File Maintenance" style="margin-left: 0.5em;">¶</a> |
877 | 916 |
<DT><A HREF="http://www.postgresql.org/docs/9.1/interactive/index.html" name="http://www.postgresql.org/docs/9.1/interactive/index.html" ADD_DATE="1317673868" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: Manuals: PostgreSQL 9.1: PostgreSQL 9.1.1 Documentation</A><a name="PostgreSQL: Documentation: Manuals: PostgreSQL 9.1: PostgreSQL 9.1.1 Documentation" href="#PostgreSQL: Documentation: Manuals: PostgreSQL 9.1: PostgreSQL 9.1.1 Documentation" style="margin-left: 0.5em;">¶</a> |
878 | 917 |
<DT><A HREF="http://www.postgresql.org/docs/8.3/static/app-psql.html" name="http://www.postgresql.org/docs/8.3/static/app-psql.html" ADD_DATE="1325722373" ICON_URI="http://www.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://www.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL: Documentation: Manuals: psql</A><a name="PostgreSQL: Documentation: Manuals: psql" href="#PostgreSQL: Documentation: Manuals: psql" style="margin-left: 0.5em;">¶</a> |
... | ... | |
1088 | 1127 |
</DL><p> |
1089 | 1128 |
<DT><a name="vacuuming" href="#vacuuming"><H3 ADD_DATE="1377911873">vacuuming</H3></a> |
1090 | 1129 |
<DL><p> |
1091 |
<DT><A HREF="http://blog.gocept.com/2012/05/22/dont-stop-postgresqls-autovacuum-with-your-application/" name="http://blog.gocept.com/2012/05/22/dont-stop-postgresqls-autovacuum-with-your-application/" ADD_DATE="1377911959" ICON_URI="http://1.gravatar.com/blavatar/b99b16aa78bd25f6aa8d01f9c1c99fb4?s=16" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://1.gravatar.com/blavatar/b99b16aa78bd25f6aa8d01f9c1c99fb4?s=16" style="margin-right: 0.5em;"/>Don’t stop PostgreSQL’s autovacuum with your application | gocept weblog</A><a name="Don’t stop PostgreSQL’s autovacuum with your application | gocept weblog" href="#Don’t stop PostgreSQL’s autovacuum with your application | gocept weblog" style="margin-left: 0.5em;">¶</a> |
|
1092 |
<DD>page's own description: The problem Some weeks ago, we received a complaint from a customer about bad PostgreSQL performance for a specific application. I took a look into the database and found strange things going on: the query planner was executing "interesting" query plans, tables were bloated with lots of dead rows (one was 6 times as big… |
|
1093 |
|
|
1094 |
"Vacuuming (whether automatic or manual) stops at the oldest transaction id that is still in use." (as opposed to skipping past any active transactions to completed ones) |
|
1095 |
|
|
1096 |
"autovacuum will abort if it is not able to obtain a table lock within one second" |
|
1097 |
"postgres[13251]: [40-1] user=,db= ERROR: canceling autovacuum task" |
|
1098 |
"I have installed a nightly cron job to force-vacuum the database. PostgreSQL has shown much improved query responses since then. Some queries’ completion times even improved by a factor of 10." |
|
1130 |
<DT><A HREF="http://dba.stackexchange.com/questions/42040/how-to-monitor-or-do-vacuum-without-stop-all" name="http://dba.stackexchange.com/questions/42040/how-to-monitor-or-do-vacuum-without-stop-all" ADD_DATE="1394172285" ICON_URI="http://cdn.sstatic.net/dba/img/favicon.ico?v=a731663709aa" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://cdn.sstatic.net/dba/img/favicon.ico?v=a731663709aa" style="margin-right: 0.5em;"/>* postgresql - How to monitor or do vacuum without stop all? - Database Administrators Stack Exchange</A><a name="* postgresql - How to monitor or do vacuum without stop all? - Database Administrators Stack Exchange" href="#* postgresql - How to monitor or do vacuum without stop all? - Database Administrators Stack Exchange" style="margin-left: 0.5em;">¶</a> |
|
1131 |
<DD>"It is safe to cancel the VACUUM FULL; doing so will undo all it's work, though" |
|
1132 |
<DT><A HREF="http://wiki.postgresql.org/wiki/VACUUM_FULL" name="http://wiki.postgresql.org/wiki/VACUUM_FULL" ADD_DATE="1340665068" ICON_URI="http://wiki.postgresql.org/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://wiki.postgresql.org/favicon.ico" style="margin-right: 0.5em;"/>* VACUUM FULL - PostgreSQL wiki</A><a name="* VACUUM FULL - PostgreSQL wiki" href="#* VACUUM FULL - PostgreSQL wiki" style="margin-left: 0.5em;">¶</a> |
|
1133 |
<DD>"ALTER TABLE .. SET DATA TYPE (relevant for 8.4 and below only) |
|
1134 |
[...] |
|
1135 |
This trick will not work in PostgreSQL versions 9.1 or later, as it detects that the change in data type is degenerate and so no rewrite is necessary." however, adding a USING clause could prevent this from being optimized away, allowing this to work in 9.1+ as well |
|
1099 | 1136 |
<DT><A HREF="http://postgresql.1045698.n5.nabble.com/How-can-I-tell-if-I-m-autovacuuming-td2085097.html" name="http://postgresql.1045698.n5.nabble.com/How-can-I-tell-if-I-m-autovacuuming-td2085097.html" ADD_DATE="1394169885" ICON_URI="http://postgresql.1045698.n5.nabble.com/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://postgresql.1045698.n5.nabble.com/favicon.ico" style="margin-right: 0.5em;"/>** PostgreSQL - admin - How can I tell if I'm autovacuuming?</A><a name="** PostgreSQL - admin - How can I tell if I'm autovacuuming?" href="#** PostgreSQL - admin - How can I tell if I'm autovacuuming?" style="margin-left: 0.5em;">¶</a> |
1100 | 1137 |
<DD>page's own description: How can I tell if I'm autovacuuming?. From what I see in the docs, these three settings in postgresql.conf should be enough for PostgreSQL (8.2) to autovacuum with the default settings: autovacuum... |
1101 | 1138 |
|
... | ... | |
1110 | 1147 |
|
1111 | 1148 |
in your server log, by setting log_min_messages to 'debug1' in your |
1112 | 1149 |
postgresql.conf." |
1150 |
<DT><A HREF="http://blog.gocept.com/2012/05/22/dont-stop-postgresqls-autovacuum-with-your-application/" name="http://blog.gocept.com/2012/05/22/dont-stop-postgresqls-autovacuum-with-your-application/" ADD_DATE="1377911959" ICON_URI="http://1.gravatar.com/blavatar/b99b16aa78bd25f6aa8d01f9c1c99fb4?s=16" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://1.gravatar.com/blavatar/b99b16aa78bd25f6aa8d01f9c1c99fb4?s=16" style="margin-right: 0.5em;"/>Don’t stop PostgreSQL’s autovacuum with your application | gocept weblog</A><a name="Don’t stop PostgreSQL’s autovacuum with your application | gocept weblog" href="#Don’t stop PostgreSQL’s autovacuum with your application | gocept weblog" style="margin-left: 0.5em;">¶</a> |
|
1151 |
<DD>page's own description: The problem Some weeks ago, we received a complaint from a customer about bad PostgreSQL performance for a specific application. I took a look into the database and found strange things going on: the query planner was executing "interesting" query plans, tables were bloated with lots of dead rows (one was 6 times as big… |
|
1152 |
|
|
1153 |
"Vacuuming (whether automatic or manual) stops at the oldest transaction id that is still in use." (as opposed to skipping past any active transactions to completed ones) |
|
1154 |
|
|
1155 |
"autovacuum will abort if it is not able to obtain a table lock within one second" |
|
1156 |
"postgres[13251]: [40-1] user=,db= ERROR: canceling autovacuum task" |
|
1157 |
"I have installed a nightly cron job to force-vacuum the database. PostgreSQL has shown much improved query responses since then. Some queries’ completion times even improved by a factor of 10." |
|
1113 | 1158 |
<DT><A HREF="http://postgresql.1045698.n5.nabble.com/Lock-problem-with-autovacuum-truncating-heap-td4265539.html" name="http://postgresql.1045698.n5.nabble.com/Lock-problem-with-autovacuum-truncating-heap-td4265539.html" ADD_DATE="1377912054" ICON_URI="http://postgresql.1045698.n5.nabble.com/favicon.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="http://postgresql.1045698.n5.nabble.com/favicon.ico" style="margin-right: 0.5em;"/>PostgreSQL - hackers - Lock problem with autovacuum truncating heap</A><a name="PostgreSQL - hackers - Lock problem with autovacuum truncating heap" href="#PostgreSQL - hackers - Lock problem with autovacuum truncating heap" style="margin-left: 0.5em;">¶</a> |
1114 | 1159 |
<DD>page's own description: Lock problem with autovacuum truncating heap. We have run across a problem with autovacuum that occurs when it can truncate off a large amount of empty blocks. It behaves different in version 9.0... |
1115 | 1160 |
|
... | ... | |
2764 | 2809 |
<DD>page's own description: Free HTML XHTML CSS JavaScript jQuery XML DOM XSL XSLT RSS AJAX ASP .NET PHP SQL tutorials, references, examples for web building. |
2765 | 2810 |
</DL><p> |
2766 | 2811 |
<DT><A HREF="https://www.google.com/search?q=%s" name="https://www.google.com/search?q=%s" ADD_DATE="1318464507" ICON_URI="https://www.google.com/favicon.ico" SHORTCUTURL="g"><img width="16" height="16" src="https://www.google.com/favicon.ico" style="margin-right: 0.5em;"/>Google</A><a name="Google" href="#Google" style="margin-left: 0.5em;">¶</a> |
2767 |
<DT><A HREF="https://www.google.com/calendar/render" name="https://www.google.com/calendar/render" ADD_DATE="1318014776" ICON_URI="https://calendar.google.com/googlecalendar/images/favicon_v2013_8.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="https://calendar.google.com/googlecalendar/images/favicon_v2013_8.ico" style="margin-right: 0.5em;"/>Google Calendar</A><a name="Google Calendar" href="#Google Calendar" style="margin-left: 0.5em;">¶</a>
|
|
2812 |
<DT><A HREF="https://www.google.com/calendar/render" name="https://www.google.com/calendar/render" ADD_DATE="1318014776" ICON_URI="https://calendar.google.com/googlecalendar/images/favicon_v2013_6.ico" LAST_CHARSET="UTF-8"><img width="16" height="16" src="https://calendar.google.com/googlecalendar/images/favicon_v2013_6.ico" style="margin-right: 0.5em;"/>Google Calendar</A><a name="Google Calendar" href="#Google Calendar" style="margin-left: 0.5em;">¶</a>
|
|
2768 | 2813 |
<DT><A HREF="javascript:(function(){var%20ca,cea,cs,df,dfe,i,j,x,y;function%20n(i,what){return%20i+%22%20%22+what+((i==1)?%22%22:%22s%22)}ca=cea=cs=0;df=document.forms;for(i=0;i<df.length;++i){x=df[i];dfe=x.elements;if(x.onsubmit){x.onsubmit=%22%22;++cs;}if(x.attributes[%22autocomplete%22]){x.attributes[%22autocomplete%22].value=%22on%22;++ca;}for(j=0;j<dfe.length;++j){y=dfe[j];if(y.attributes[%22autocomplete%22]){y.attributes[%22autocomplete%22].value=%22on%22;++cea;}}}alert(%22Removed%20autocomplete=off%20from%20%22+n(ca,%22form%22)+%22%20and%20from%20%22+n(cea,%22form%20element%22)+%22,%20and%20removed%20onsubmit%20from%20%22+n(cs,%22form%22)+%22.%20After%20you%20type%20your%20password%20and%20submit%20the%20form,%20the%20browser%20will%20offer%20to%20remember%20your%20password.%22)})();" name="javascript:(function(){var%20ca,cea,cs,df,dfe,i,j,x,y;function%20n(i,what){return%20i+%22%20%22+what+((i==1)?%22%22:%22s%22)}ca=cea=cs=0;df=document.forms;for(i=0;i<df.length;++i){x=df[i];dfe=x.elements;if(x.onsubmit){x.onsubmit=%22%22;++cs;}if(x.attributes[%22autocomplete%22]){x.attributes[%22autocomplete%22].value=%22on%22;++ca;}for(j=0;j<dfe.length;++j){y=dfe[j];if(y.attributes[%22autocomplete%22]){y.attributes[%22autocomplete%22].value=%22on%22;++cea;}}}alert(%22Removed%20autocomplete=off%20from%20%22+n(ca,%22form%22)+%22%20and%20from%20%22+n(cea,%22form%20element%22)+%22,%20and%20removed%20onsubmit%20from%20%22+n(cs,%22form%22)+%22.%20After%20you%20type%20your%20password%20and%20submit%20the%20form,%20the%20browser%20will%20offer%20to%20remember%20your%20password.%22)})();" ADD_DATE="1318292619" SHORTCUTURL="r"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>remember password</A><a name="remember password" href="#remember password" style="margin-left: 0.5em;">¶</a> |
2769 | 2814 |
<HR> <DT><A HREF="place:sort=14&type=6&maxResults=10&queryType=1" name="place:sort=14&type=6&maxResults=10&queryType=1"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>Recent Tags</A><a name="Recent Tags" href="#Recent Tags" style="margin-left: 0.5em;">¶</a> |
2770 | 2815 |
<DT><A HREF="place:folder=BOOKMARKS_MENU&folder=UNFILED_BOOKMARKS&folder=TOOLBAR&sort=12&excludeQueries=1&maxResults=10&queryType=1" name="place:folder=BOOKMARKS_MENU&folder=UNFILED_BOOKMARKS&folder=TOOLBAR&sort=12&excludeQueries=1&maxResults=10&queryType=1"><img width="16" height="16" src="blank.gif" style="margin-right: 0.5em;"/>Recently Bookmarked</A><a name="Recently Bookmarked" href="#Recently Bookmarked" style="margin-left: 0.5em;">¶</a> |
Also available in: Unified diff
web/links/index.htm: updated to Firefox bookmarks: PostgreSQL: added description of join_collapse_limit config param (which should be turned off, although it is on by default). added links for using TIDs ("the fastest possible access to a single row").