Re: Slow join on partitioned table

From: Conor Walsh <ctw(at)adverb(dot)ly>
To: Mark Thornton <mthornton(at)optrak(dot)co(dot)uk>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow join on partitioned table
Date: 2011-03-09 22:42:28
Message-ID: AANLkTimaAyE0WQg-VS=RzdhrN--EMJ0wAEy=-5Zu4gBT@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Mar 4, 2011 at 8:47 AM, Mark Thornton <mthornton(at)optrak(dot)co(dot)uk> wrote:
> It is a temporary table and thus I hadn't thought to analyze it. How should
> such tables be treated? Should I analyze it immediately after creation (i.e.
> when it is empty), after filling it or ... ? The expected usage is such that
> the temporary table will have less than 100 or so rows.

When in doubt, analyze.

If you're engaging in OLAP, or some other workload pattern that
involves writing many small batches, then analyzing all the time is
bad. If you're engaged in any workload that writes rarely - a bulk
insert here, a create-table-as-select there, etc - always analyze.

The cost of analyzing when you shouldn't is low and O(1) per analysis,
and the cost of not analyzing when you should have can easily be
O(n^2) or worse w/r/t data size.

The cost of analyzing is especially low on a temp table only owned by
your current session, because no one else will be disturbed by the
table lock you acquire if you context-switch out before it's done.

-Conor

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jim Nasby 2011-03-09 23:01:23 Re: NULLS LAST performance
Previous Message Jim Nasby 2011-03-09 22:01:58 Re: Table partitioning problem