On Fri, Mar 4, 2011 at 8:47 AM, Mark Thornton mthorn...@optrak.co.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
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
On Fri, Mar 4, 2011 at 6:40 AM, Mark Thornton mthorn...@optrak.co.uk 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
On 04/03/2011 16:07, Robert Haas wrote:
On Fri, Mar 4, 2011 at 6:40 AM, Mark Thorntonmthorn...@optrak.co.uk 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).
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
On Fri, Mar 4, 2011 at 12:00 PM, Mark Thornton mthorn...@optrak.co.uk 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
