Tom Lane <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> writes:
> > But on that note, is it ok to use the bulkdelete index AM methods for
> > non-vacuum purposes
>
> Um, what would those be?
I'm sure with a little work I can imagine lots of reasons to want to pull out
all the index tuples from an index other than vacuum. I can't actually name
any right now, but I'm sure I'll think of some :)
> ambulkdelete and amvacuumcleanup are most certainly not designed to be
> used in any context other than VACUUM. You might be able to abuse them
> for some other purpose, but don't expect a warranty.
What I'm doing now is calling ambulkdelete with a callback that returns false
for every tuple and stuffs the item pointer into a data structure. It seems to
be working but I haven't tested it thoroughly yet.
I'm worried that ambulkdelete might have side effects on the index that aren't
obvious. Other than bumping the vacuum cycle id I don't see any in a quick
scan of the btree code. But I could have missed something or other access
methods could behave differently.
I would be happier with a generic "index sequential scan" interface. I realize
the cycle id trick restricts any such api to a single scanner at a time which
is fine for my purposes.
Actually is that really true? Wouldn't the cycle id setup work fine if a
subsequent scan started and the cycle id was bumped a second time? If you find
a page that was split with a cycle id greater than yours then you still know
it was split after you started. As long as the cycle id doesn't wrap while a
scan is proceeding it should be fine. Perhaps tagging the split pages with the
xid of the most recent scan instead of a separate cycle id concept?
--
greg
