Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Clodoaldo <clodoaldo(dot)pinto(dot)neto(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, PostgreSQL - General ML <pgsql-general(at)postgresql(dot)org>
Subject: Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?
Date: 2008-01-20 18:20:01
Message-ID: 10297.1200853201@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane escribi:
>> In the long run, for queries inserting many rows it might be interesting
>> to accumulate all the entries intended for a btree index and sort them
>> before inserting. Not sure about possible downsides of that.

> Yeah, in the long run we need a more flexible approach towards index
> insertion. I doubt we want to know _all_ the entries beforehand; that
> would probably involve disk-spilling, etc. Perhaps accumulate a
> reasonable number (using up to work_mem?) and insert those in batches.

After sleeping on it, the main problem I can see is that it'd mean the
index is transiently invalid. As an example of the problem, it's always
been true in the past that a BEFORE INSERT trigger could "see" rows
already inserted by the calling command --- but if it chanced to try to
use an index with delayed insertions, it might not see them. You could
work around this if the indexscan code knew to go search in the list of
pending insertions, but that's pretty ugly and possibly slow too.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2008-01-20 18:40:14 Re: Sun acquires MySQL
Previous Message Tom Lane 2008-01-20 18:13:37 Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?