Re: [CDBI] Make CDBI go fast

On 3/21/07, Brad Bowman <[email protected]> wrote:
> That's what I was thinking, do one table scan keeping a sorted set of
> the top $N, comparing each scanned row with the last of the current
> row set.  Then the set is then kept in an index and maintained during
> insertions (easy) and deletions (if one of the set is deleted a scan
> may be needed) and updates.

That's exactly what an index is.  Once it has been sorted, keeping it
sorted is not that big a hit.  It's probably a BTree.

> The benefits would be less space used and lower maintenance overhead
> than a full index.

Once you've done the initial sort when building the index, I doubt it
makes much difference.

The Pg partial index thing doesn't sound applicable.  I suspect that
if you tried to give it criteria that would limit based on a sort
order, it would either fail or have to sort the whole table every time
you did a delete.  By definition, you wouldn't have an index that it
can use to determine the next row after the indexed ones, so when one
of them goes away...

- Perrin