On Tue, 2008-02-26 at 09:08 +, Simon Riggs wrote:
> I very much like the idea of index merging, or put another way: batch
> index inserts. How big do the batch of index inserts have to be for us
> to gain benefit from this technique? Would it be possible to just buffer
> the index inserts insi
Added to TODO:
o Allow COPY FROM to create index entries in bulk
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php
---
ITAGAKI Takahiro wrote:
> This is a proposal of fast data loading us
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Can we do REINDEX
>>> holding only shared lock on the index?
>>
>> No. When you commit the reindex, the old copy of the index will
>> instantaneously disappear; it will not do for someone to be actively
>> scan
Tom Lane <[EMAIL PROTECTED]> wrote:
> > Can we do REINDEX
> > holding only shared lock on the index?
>
> No. When you commit the reindex, the old copy of the index will
> instantaneously disappear; it will not do for someone to be actively
> scanning that copy.
Hmm... Is it ok if the index wil
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> 2008/2/29, Tom Lane <[EMAIL PROTECTED]>:
>> No. When you commit the reindex, the old copy of the index will
>> instantaneously disappear; it will not do for someone to be actively
>> scanning that copy.
> Can a shared lock be taken at first, and whe
2008/2/29, Tom Lane <[EMAIL PROTECTED]>:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > BTW, why REINDEX requires access exclusive lock? Read-only queries
> > are forbidden during the operation now, but I feel they are ok
> > because REINDEX only reads existing tuples. Can we do REINDEX
> >
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> BTW, why REINDEX requires access exclusive lock? Read-only queries
> are forbidden during the operation now, but I feel they are ok
> because REINDEX only reads existing tuples. Can we do REINDEX
> holding only shared lock on the index?
No. When you
Simon Riggs <[EMAIL PROTECTED]> wrote:
> The LOCK is only required because we defer the inserts into unique
> indexes, yes?
No, as far as present pg_bulkload. It creates a new relfilenode like REINDEX,
therefore, access exclusive lock is needed. When there is violations of
unique constraints, al
On Tue, 2008-02-26 at 15:19 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > One of the reasons why I hadn't wanted to pursue earlier ideas to use
> > LOCK was that applying a lock will prevent running in parallel, which
> > ultimately may prevent further performance g
Simon Riggs <[EMAIL PROTECTED]> wrote:
> One of the reasons why I hadn't wanted to pursue earlier ideas to use
> LOCK was that applying a lock will prevent running in parallel, which
> ultimately may prevent further performance gains.
>
> Is there a way of doing this that will allow multiple conc
On Thu, 2008-02-21 at 13:26 +0900, ITAGAKI Takahiro wrote:
> This is a proposal of fast data loading using batch update of indexes for 8.4.
> It is a part of pg_bulkload (http://pgbulkload.projects.postgresql.org/) and
> I'd like to integrate it in order to cooperate with other parts of postgres.
>
Itagaki-san,
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > The basic concept is spooling new coming data, and merge the spool and
> > > the existing indexes into a new index at the end of data loading. It is
> > > 5-10 times faster than index insertion per-row, that is the way in 8.3.
Thanks
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > The basic concept is spooling new coming data, and merge the spool and
> > the existing indexes into a new index at the end of data loading. It is
> > 5-10 times faster than index insertion per-row, that is the way in 8.3.
>
> Please see
> http://th
ITAGAKI Takahiro wrote:
> The basic concept is spooling new coming data, and merge the spool and
> the existing indexes into a new index at the end of data loading. It is
> 5-10 times faster than index insertion per-row, that is the way in 8.3.
Please see
http://thread.gmane.org/gmane.comp.db.p
This is a proposal of fast data loading using batch update of indexes for 8.4.
It is a part of pg_bulkload (http://pgbulkload.projects.postgresql.org/) and
I'd like to integrate it in order to cooperate with other parts of postgres.
The basic concept is spooling new coming data, and merge the spoo
15 matches
Mail list logo
