Re: issue with query optimizer when joining two partitioned tables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2011-07-09 18:43, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakangas@xxxxxxxxxxxxxxxx>  writes:
On 09.07.2011 00:36, Anish Kejariwal wrote:
My guess as to what happened:
-because the icecream parent table has zero records, the query optimizer
chooses the incorrect execution plan
-when I do select * from icecream, the optimizer now knows how many records
are really in the icecream table, by knowing that the icecream table has
partitions.

"select * from icecream" won't have any direct effect on the
optimization of subsequent queries. What probably happened is that
autoanalyze ran in the background while you ran that select, and
analyzed some of the partitions. Simply waiting a while would've had the
same effect.

Yeah.  Also, the reason that a manual vacuum on icecream changes things
yet again is that in 9.0 and up, we have a notion of summary stats
across the whole inheritance tree, but autoanalyze hasn't been taught to
gather those.  The manual command on the parent table does gather them,
though.

Is stats-gathering significantly more expensive than an FTS?   Could an FTS
update stats as a matter of course (or perhaps only if enough changes in table)?
--
Jeremy

--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux