On Wed, Apr 25, 2012 at 12:18 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Apr 25, 2012 at 12:08 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> On Wed, Apr 25, 2012 at 4:49 PM, Robert Haas <robertmh...@gmail.com> wrote: >>>> How important is support for VACUUM on these tables under hot standby? The >>>> alternative is to fail when a session retains a temporary table across 2B >>>> local transactions. I do not currently see any challenges sufficient to >>>> motivate not supporting VACUUM, but it might be a useful simplification to >>>> keep in mind. What about ANALYZE support; how important is the ability to >>>> collect statistics on temporary tables? Again, I tentatively expect to >>>> support it regardless of the answer. >>> >>> I think it's probably pretty important to support VACUUM, because even >>> ignoring wraparound considerations, not vacuuming tends to cause >>> performance to suck. I think ANALYZE is less important for the >>> reasons stated above. >> >> ANALYZE is essential for temp tables in many cases... not sure what >> the "reasons stated above" were, I can't resolve that reference. > > My theory is that users of a global temp table will have > similar-enough usage patterns that a set of statistics that is good > enough for one user will be good enough for all of them. That might > not be true in all cases, but I think it will simplify things quite a > bit to assume it true for purposes of an initial implementation. And > as I noted, in some cases it might be a clear improvement: right now, > after creating a temp table, you've got to analyze it or you'll just > get the default statistics, which figure to be terrible. Inheriting > the statistics left over from the last guy's analyze figures to be > significantly superior.
Oh, we're talking about different things, and I'm slightly confused. Yes, we need to support ANALYZE; what we might not need to support, at least initially, is every user of a global temp table having their own SEPARATE copy of the table statistics. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
