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
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 |