On Sun, Jun 21, 2009 at 5:07 PM, Robert Haas<robertmhaas@gmail.com> wrote:
>
> I think we had the idea of buffering up enough tuples to fill a page
> (estimating conservatively so as to make sure we actually fill it),
> and then inserting them all at once. But I'm not sure how much
> trouble that causes in terms of the timing of inserting index entries
> and firing of after row insert triggers. If the command ID doesn't
> change, it seems like it might be OK. Or at worst, even if the
> optimization would only work in cases where there are no after row
> triggers, that would still be useful to a lot of people, I think.
>
> I haven't really spent much time on this angle of attack and
> completely confess to not understanding all of the issues...
There was some discussion of doing this in general for all inserts
inside the indexam. The btree indexam could buffer up any inserts done
within the transaction and keep them in an in-memory btree. Any
lookups done within the transaction first look up in the in-memory
tree then the disk. If the in-memory buffer fills up then we flush
them to the index.
The reason this is tempting is that we could then insert them all in a
single index-merge operation which would often be more efficient than
retail inserts.
--
greg
http://mit.edu/~gsstark/resume.pdf