| 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-16 15:29:39 |
| Message-ID: | 1287242940-sup-5258@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 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.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bernd Helmle | 2010-10-16 16:05:54 | Re: Trailing Whitespace Tips (was: Re: starting to review the Extend NOT NULL representation to pg_constraint patch) |
| Previous Message | Alvaro Herrera | 2010-10-16 15:27:17 | Re: Keywords in pg_hba.conf should be field-specific |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mladen Gogala | 2010-10-16 16:51:59 | Select count(*), the sequel |
| Previous Message | Eric Comeau | 2010-10-16 12:32:11 | Help with duration of statement: EXECUTE <unnamed> [PREPARE: COMMIT] |