[CDBI] Make CDBI go fast
pharkins at gmail.com
Thu Mar 22 03:17:29 GMT 2007
On 3/21/07, Brad Bowman <list at bereft.net> 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...
More information about the ClassDBI