Content-Type: text/plain; charset=UTF-8
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
	Bruce Momjian <bruce@momjian.us>, Kris Jurka <books@ejurka.com>,
	pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: No hash join across partitioned tables?
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Samuel Gendler <sgendler@ideasculptor.com>
In-reply-to: <AANLkTim3PgeBNsGujstuAD-Z+TPNgQ+7Ucw3Oy87hAAb@mail.gmail.com>
References: <201002252346.o1PNkXG07892@momjian.us>
	<9477.1267142614@sss.pgh.pa.us>
	<603c8f071003020816j77b3ec63wbad0415df003c0f1@mail.gmail.com>
	<17546.1267546998@sss.pgh.pa.us>
	<AANLkTinx8lLTEKWcyEQ1rxVz6WMJVKNezfXW5TKnNAU6@mail.gmail.com>
	<1287205016-sup-542@alvh.no-ip.org>
	<29559.1287206562@sss.pgh.pa.us>
	<AANLkTim1+h8jgOV6iEoN8OxF19MTb+wHFDMP8_tKdONp@mail.gmail.com>
	<1287242940-sup-5258@alvh.no-ip.org>
	<AANLkTim3PgeBNsGujstuAD-Z+TPNgQ+7Ucw3Oy87hAAb@mail.gmail.com>
Date: Mon, 18 Oct 2010 11:44:53 -0300
Message-Id: <1287412944-sup-7251@alvh.no-ip.org>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit

Excerpts from Samuel Gendler's message of lun oct 18 03:13:01 -0300 2010:
> On Sat, Oct 16, 2010 at 8:29 AM, Alvaro Herrera
> <alvherre@commandprompt.com>wrote:
> 
> > Excerpts from Samuel Gendler's message of sáb oct 16 02:35:46 -0300 2010:
> >
> > > An issue with automatically analyzing the entire hierarchy is
> > > 'abstract' table definitions.  I've got a set of tables for
> > > storing the same data at different granularities of aggregation.
> > > Within each granularity, I've got partitions, but because the set
> > > of columns is identical for each granularity, I've got an abstract
> > > table definition that is inherited by everything.  I don't need or
> > > want statistics kept on that table because I never query across
> > > the abstract table, only the parent table of each aggregation
> > > granularity
> >
> > Hmm, I think you'd be better served by using LIKE instead of regular
> > inheritance.
>
> Yep.  I inherited the architecture, though, and changing it hasn't been a
> high priority.

I understand that; my point is merely that maybe we shouldn't work
through many hoops to solve this particular facet of the problem,
because it seems to be pilot error.  (If you really needed to avoid the
extra I/O that would be caused by unnecessary analyzes, you could turn
autovac off for the abstract tables).

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support