Re: No hash join across partitioned tables?

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Samuel Gendler <sgendler(at)ideasculptor(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Kris Jurka <books(at)ejurka(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: No hash join across partitioned tables?
Date: 2010-10-18 14:44:53
Message-ID: 1287412944-sup-7251@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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(at)commandprompt(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-10-18 14:52:21 Re: WIP: extensible enums
Previous Message Josh Kupershmidt 2010-10-18 14:43:32 Re: [GENERAL] column-level update privs + lock table

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2010-10-18 15:02:15 Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]
Previous Message Mladen Gogala 2010-10-18 14:25:17 Re: Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT]