| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 9.3 Pre-proposal: Range Merge Join |
| Date: | 2012-04-16 21:20:03 |
| Message-ID: | CA+U5nMJ_c=AfoEmbceR_F8w8j_LYY+Ax0CLU8vjveDeYoFzEFg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 16, 2012 at 9:12 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> That had occurred to me, but I was hesitant to only use temp indexes. It
> still doesn't really offer a good solution when both sides of the join
> are relatively large (because of random I/O). Also the build speed of
> the index would be more important than it is now.
The thing I like most about temp indexes is that they needn't be temporary.
I'd like to see something along the lines of demand-created optional
indexes, that we reclaim space/maintenance overhead on according to
some cache management scheme. More space you have, the more of the
important ones hang around. The rough same idea applies to
materialised views.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2012-04-16 21:42:42 | Re: Memory usage during sorting |
| Previous Message | Alexander Korotkov | 2012-04-16 21:19:53 | Re: 9.3 Pre-proposal: Range Merge Join |