On Fri, Mar 4, 2011 at 8:47 AM, Mark Thornton 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 tem
On Fri, Mar 4, 2011 at 12:00 PM, Mark Thornton wrote:
> On 04/03/2011 16:07, Robert Haas wrote:
>>
>> That seems quite surprising. There are only 14 rows in the table but
>> PG thinks 2140? Do you have autovacuum turned on? Has this table
>> been analyzed recently?
>>
> I think autovacuum is ena
On 04/03/2011 16:07, Robert Haas wrote:
That seems quite surprising. There are only 14 rows in the table but
PG thinks 2140? Do you have autovacuum turned on? Has this table
been analyzed recently?
I think autovacuum is enabled, but as a temporary table LinkIds has only
existed for a very sho
On 04/03/2011 16:07, Robert Haas wrote:
On Fri, Mar 4, 2011 at 6:40 AM, Mark Thornton wrote:
I can achieve this manually by rewriting the query as a union between
queries against each of the child tables. Is there a better way? (I'm using
PostGreSQL 8.4 with PostGIS 1.4).
Can you post the EXPL
On Fri, Mar 4, 2011 at 6:40 AM, Mark Thornton wrote:
> The query plan appends sequential scans on the tables in the partition (9
> tables, ~4 million rows) and then hash joins that with a 14 row table. The
> join condition is the primary key of each table in the partition (and would
> be the prima
The query plan appends sequential scans on the tables in the partition
(9 tables, ~4 million rows) and then hash joins that with a 14 row
table. The join condition is the primary key of each table in the
partition (and would be the primary key of the parent if that was
supported).
It would be m
