Re: Tow kinds of different result while using create index concurrently

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: 高健 <luckyjackgao(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Tow kinds of different result while using create index concurrently
Date: 2013-06-20 17:36:56
Message-ID: CAMkU=1wrfyJEbsC8ta1y8DQocHFRngGkcdepruLBAuo2m63USg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jun 20, 2013 at 1:27 AM, 高健 <luckyjackgao(at)gmail(dot)com> wrote:

> Hello:
>
>
>
> I have question about PG's "create index concurrently". I think it is a
> bug perhaps.
>
>
>
> I make two tables tab01 and tab02, they have no relationships.
>
> I think "create index concurrently " on tab02 will not be influenced by
> transaction on tab01.
>
> But the result differs:
>

This is expected. In order to not interfere with "normal" activity, a
concurrent index build has to volunteer to be blocked by such activity
instead. From the doc: "When this option is used, PostgreSQL must perform
two scans of the table, and in addition it must wait for all existing
transactions that could potentially use the index to terminate."

Now in your case, perhaps the argument could be made that the transaction
hosting the 1st concurrent build could not potentially use the 2nd-building
index, but there is no convenient way for PostgreSQL to detect that fact.

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Janes 2013-06-20 18:07:39 Re: Do not understand high estimates of index scan vs seq scan
Previous Message Leif Biberg Kristensen 2013-06-20 16:28:37 Re: coalesce function