Re: autovacuum and temp tables support - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: autovacuum and temp tables support
Date
Msg-id 201004160222.o3G2Mcm09238@momjian.us
Whole thread Raw
In response to Re: autovacuum and temp tables support  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas wrote:
> On Thu, Apr 8, 2010 at 3:22 PM, Oleg Bartunov <oleg@sai.msu.su> wrote:
> >> On general thought I've had is that it would be nice if the first
> >> attempt to SELECT against a table with no statistics would trigger an
> >> automatic ANALYZE by the backend on which the query was executed.
> >> It's pretty common to populate a table using INSERT, or CTAS, or COPY
> >> and then try to immediately run a query against it, and I've often
> >> found that it's necessary to insert manual analyze statements in there
> >> to get decent query plans.
> >
> > Oracle does this. So, is't worth to add support (configurable, like
> > Oracle's optimizer_dynamic_sampling) ?
>
> Well, dynamic sampling is considerably more complicated than what I
> proposed, which is just to force an ordinary ANALYZE before the first
> query against the table.  It would be a very powerful feature if we
> could use it to ameliorate, for example, the gross statistical errors
> that sometimes occur when multiple, correlated filter conditions are
> applied to the same base table; but I don't think it's in the direct
> path of solving the present complaint.

I have added this TODO:

    Consider analyzing temporary tables when they are first used in a query

        Autovacuum cannot analyze or vacuum temporary tables.

            * http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php

I have also applied the following documentation patch to document this
behavior.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
Index: doc/src/sgml/maintenance.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v
retrieving revision 1.102
diff -c -c -r1.102 maintenance.sgml
*** doc/src/sgml/maintenance.sgml    3 Apr 2010 07:22:55 -0000    1.102
--- doc/src/sgml/maintenance.sgml    16 Apr 2010 02:21:23 -0000
***************
*** 643,648 ****
--- 643,654 ----
     </para>

     <para>
+     Temporary tables cannot be accessed by autovacuum.  Therefore,
+     appropriate vacuum and analyze operations should be performed via
+     session SQL commands.
+    </para>
+
+    <para>
      The default thresholds and scale factors are taken from
      <filename>postgresql.conf</filename>, but it is possible to override them
      on a table-by-table basis; see
Index: doc/src/sgml/ref/create_table.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v
retrieving revision 1.125
diff -c -c -r1.125 create_table.sgml
*** doc/src/sgml/ref/create_table.sgml    3 Apr 2010 07:23:00 -0000    1.125
--- doc/src/sgml/ref/create_table.sgml    16 Apr 2010 02:21:27 -0000
***************
*** 145,150 ****
--- 145,159 ----
       </para>

       <para>
+       The <link linkend="autovacuum">autovacuum daemon</link> cannot
+       access and therefore cannot vacuum or analyze temporary tables.
+       For this reason, appropriate vacuum and analyze operations should be
+       performed via session SQL commands.  For example, if a temporary
+       table is going to be used in complex queries, it is wise to run
+       <command>ANALYZE</> on the temporary table after it is populated.
+      </para>
+
+      <para>
        Optionally, <literal>GLOBAL</literal> or <literal>LOCAL</literal>
        can be written before <literal>TEMPORARY</> or <literal>TEMP</>.
        This makes no difference in <productname>PostgreSQL</>, but see

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pgindent and tabs in comments
Next
From: John R Pierce
Date:
Subject: solaris sparc 64bit binary release