Project

General

Profile

« Previous | Next » 

Revision 12622

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").

View differences:

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;">&para;</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&#39;t have a unique identifier available. The table...
687

  
688
&quot;Joins on tid columns just aren&#39;t supported very well at the moment. [...] There are gotchas if any of the rows receive concurrent updates.&quot; (Tom Lane)
689

  
690
&quot;type tid doesn&#39;t have any hash support&quot; (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;">&para;</a>
692
<DD>&quot;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&#39;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.&quot;
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;">&para;</a>
695
<DD>&quot;
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
&quot;
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;">&para;</a>
702
<DD>&quot;It is scanning table by TupleID&#39;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.&quot;
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;">&para;</a>
707
<DD>&quot;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.&quot;
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;">&para;</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;">&para;</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;">&para;</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;">&para;</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;">&para;</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;">&para;</a>
......
730 755
if you try to disable a foreign key constraint&#39;s trigger, you will get an error, even if it is marked NOT VALID: 
731 756
&quot;ERROR: permission denied: &quot;RI_ConstraintTrigger_...&quot; is a system trigger
732 757
SQL state: 42501&quot;
758

  
759
&quot;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.&quot;
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;">&para;</a>
734 761
<DD>&quot;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&quot;
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;">&para;</a>
......
867 894
<DD>&quot;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.&quot;
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;">&para;</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;">&para;</a>
898
<DD>-
899
**** &quot;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.&quot;
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;">&para;</a>
871 904
<DD>&quot;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.&quot;
872 905

  
873 906
&quot;This feature is disabled by default for manually issued VACUUM commands.&quot; 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;">&para;</a>
875 908
<DD>&quot;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&#39;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.&quot;
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;">&para;</a>
910
<DD>&quot;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&#39;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.&quot;
912

  
913
&quot;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&#39;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.&quot;
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;">&para;</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;">&para;</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;">&para;</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;">&para;</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 &quot;interesting&quot; query plans, tables were bloated with lots of dead rows (one was 6 times as big…
1093

  
1094
&quot;Vacuuming (whether automatic or manual) stops at the oldest transaction id that is still in use.&quot; (as opposed to skipping past any active transactions to completed ones)
1095

  
1096
&quot;autovacuum will abort if it is not able to obtain a table lock within one second&quot;
1097
&quot;postgres[13251]: [40-1] user=,db= ERROR:  canceling autovacuum task&quot;
1098
&quot;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.&quot;
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;">&para;</a>
1131
<DD>&quot;It is safe to cancel the VACUUM FULL; doing so will undo all it&#39;s work, though&quot;
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;">&para;</a>
1133
<DD>&quot;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.&quot; 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&#39;m autovacuuming?</A><a name="** PostgreSQL - admin - How can I tell if I&#39;m autovacuuming?" href="#** PostgreSQL - admin - How can I tell if I&#39;m autovacuuming?" style="margin-left: 0.5em;">&para;</a>
1100 1137
<DD>page's own description: How can I tell if I&#39;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 &#39;debug1&#39; in your
1112 1149
postgresql.conf.&quot;
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;">&para;</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 &quot;interesting&quot; query plans, tables were bloated with lots of dead rows (one was 6 times as big…
1152

  
1153
&quot;Vacuuming (whether automatic or manual) stops at the oldest transaction id that is still in use.&quot; (as opposed to skipping past any active transactions to completed ones)
1154

  
1155
&quot;autovacuum will abort if it is not able to obtain a table lock within one second&quot;
1156
&quot;postgres[13251]: [40-1] user=,db= ERROR:  canceling autovacuum task&quot;
1157
&quot;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.&quot;
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;">&para;</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;">&para;</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;">&para;</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;">&para;</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;">&para;</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;">&para;</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;">&para;</a>

Also available in: Unified diff