| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Iain" <iain(at)mst(dot)co(dot)jp>, "Joe Conway" <mail(at)joeconway(dot)com>, "Christopher Browne" <cbbrowne(at)acm(dot)org> |
| Cc: | <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Data Warehouse Reevaluation - MySQL vs Postgres -- |
| Date: | 2004-09-17 07:39:10 |
| Message-ID: | NOEFLCFHBPDAFHEIPGBOMEKJCEAA.simon@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> Iain
> Joe's example wasn't excluding partions, as he didn't use a
> predicated UNION
> ALL view to select from. His queries use an indexed column that allow the
> various partitions to be probed at low cost, and he was satisfied
> wth that.
Agreed - very very interesting design though.
> My point in my previous post was that you could still do all that that if
> you wanted to, by building the predicated view with UNION ALL of
> each of the
> child tables.
>
AFAICS of all the designs proposed there is still only one design *using
current PostgreSQL* that allows partitions to be excluded from queries as a
way of speeding up queries against very large tables: UNION ALL with
appended constants.
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2004-09-17 17:40:18 | Re: Large # of rows in query extremely slow, not using |
| Previous Message | Joshua D. Drake | 2004-09-17 03:14:16 | Re: Large # of rows in query extremely slow, not using |