From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Thomas Munro <munro(at)ip9(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: ctid ranges |
Date: | 2012-06-13 20:18:16 |
Message-ID: | 20120613201816.GF4418@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Jun 13, 2012 at 03:15:14PM -0500, Merlin Moncure wrote:
> On Mon, Jun 11, 2012 at 7:57 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > On Fri, 2012-06-08 at 22:27 +0100, Thomas Munro wrote:
> >> This is slow, handled with a seq scan (as are various rephrasing with
> >> <, <=, etc):
> >>
> >> SELECT ... FROM ... WHERE ctid BETWEEN ... AND ...;
> >>
> >> Is there a way to retrieve the rows in a physical range quickly?
> >
> > Interesting idea. However, as far as I know, there is no such support.
>
> yeah -- and I think it's a great thing to want to be able to do. it
> could be used in parallelizing tricks for example: divide up a table
> into N approximately equal parts and hand each one off to a work
> thread.
Can we add this as a TODO? It would basically be adding
less/greater-than comparisons for the 'tid' data type.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-06-13 20:21:17 | Re: ctid ranges |
Previous Message | Merlin Moncure | 2012-06-13 20:15:14 | Re: ctid ranges |