Bruce Momjian [EMAIL PROTECTED] wrote:
The attached patch requires the new row to fit, and 10% to be free on
the page. Would someone test that?
This is another solution for the same purpose. We can avoid to call
PageIndexMultiDelete() to remove only one tuple. _bt_split() becomes
to ignore
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
The problem is that we've traded splitting a page every few hundred
inserts for doing a PageIndexMultiDelete, and emitting an extra WAL
record, on *every* insert. This is not good.
I suspect PageIndexMultiDelete()
Tom Lane [EMAIL PROTECTED] wrote:
I think the only serious objection to this would be that it'd mean that
tuples that should have an index entry might not have one.
This can occurs when we do REINDEX after DELETE, because dead tuples are
excluded on REINDEX. So we cannot guarantee that all
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I think the only serious objection to this would be that it'd mean that
tuples that should have an index entry might not have one.
This can occurs when we do REINDEX after DELETE, because dead tuples are
excluded on
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I've applied this but I'm now having some second thoughts about it,
because I'm seeing an actual *decrease* in pgbench numbers from the
immediately prior CVS HEAD code.
Had you done any performance testing on this
On Wed, Jul 12, 2006 at 03:59:01PM +0900, ITAGAKI Takahiro wrote:
Hi Hackers,
Can we resurrect the patch proposed by Junji TERAMOTO?
It removes unnecessary items before btree pages split.
http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
There was a problem in the patch
