Jim,
> I know there were discussions in the past, though as per usual I can't
> find them in the archives.
Search on "B-Tree Organized Tables".
>From what I can find, this feature isn't prohibitively useless. It's just a
singnificant amount of effort for a result which is a tradeoff. That is
On Jun 27, 2006, at 9:39 AM, Jim C. Nasby wrote:
I think one of the issues might have been: how will you handle other
indexes on the table when you can no longer point them at an item
(since
items will need to move to maintain an IOT).
There are clean ways to handle this. The table is org
> I think one of the issues might have been: how will you handle other
> indexes on the table when you can no longer point them at an item (since
> items will need to move to maintain an IOT).
I guess you shouldn't allow any other indexes. That's a perfectly
acceptable compromise I think... it wou
On Mon, Jun 26, 2006 at 11:31:24PM -0700, Luke Lonergan wrote:
> Jim,
>
> On 6/26/06 8:15 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> > On a somewhat related note, I think that it would be advantageous if the
> > FSM had a means to prefer certain pages for a given tuple over other
> > pages
Jim C. Nasby wrote:
On Sun, Jun 25, 2006 at 08:04:18PM -0400, Luke Lonergan wrote:
Other DBMS have index organized tables that can use either hash or btree
organizations, both of which have their uses. We are planning to
implement btree organized tables sometime - anyone else interested in
t
Jim,
On 6/26/06 8:15 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On a somewhat related note, I think that it would be advantageous if the
> FSM had a means to prefer certain pages for a given tuple over other
> pages. This would allow for a better way to keep heap and possibly index
> data mo
On Sun, Jun 25, 2006 at 08:04:18PM -0400, Luke Lonergan wrote:
> Other DBMS have index organized tables that can use either hash or btree
> organizations, both of which have their uses. We are planning to
> implement btree organized tables sometime - anyone else interested in
> this idea?
I'm cur
Luke,
> Other DBMS have index organized tables that can use either hash or btree
> organizations, both of which have their uses. We are planning to
> implement btree organized tables sometime - anyone else interested in
> this idea?
Search the archives. It's been dicussed on this list at least
Dawid,
> Other idea than using histogram_bounds would be using the
> position of key inside the index to determine the "ideal"
> place of row inside the table and find the closest free spot
> there. This would be of course much more precise and wouldn't
> rely on statistic.
This is generally
