On Sun, Jul 12, 2009 at 4:42 PM, Tom Lane wrote:
>
> I'm kind of wondering how big the use case for that really is.
> AFAICT the point of a concurrent build is to (re)build an index
> without incurring too much performance penalty for foreground
> query processing. So how often are you really goin
Actually ... why do we have to have that third wait step at all?
Doesn't the indcheckxmin mechanism render it unnecessary, or couldn't
we adjust the comparison xmin to make it unnecessary?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Greg Stark writes:
> So I think we're back to looking at a special case for concurrent
> index builds to not wait on other concurrent index builds.
I'm kind of wondering how big the use case for that really is.
AFAICT the point of a concurrent build is to (re)build an index
without incurring too
On Sun, Jul 12, 2009 at 4:17 PM, Tom Lane wrote:
> The requirement wasn't just on not changing SQL data though. To make
> use of this you'd also have to forbid indexed functions from *reading*
> other tables. Which is something we discourage because of the risk that
> the results aren't really im
Josh Berkus writes:
> On 7/11/09 3:50 AM, Greg Stark wrote:
>> Hm. Actually maybe not. What if the index is an expression index and
>> the expression includes a function which does an SQL operation? I'm
>> not sure how realistic that is since to be a danger that SQL operation
>> would have to be a
On 7/11/09 3:50 AM, Greg Stark wrote:
Hm. Actually maybe not. What if the index is an expression index and
the expression includes a function which does an SQL operation? I'm
not sure how realistic that is since to be a danger that SQL operation
would have to be an insert, update, or delete which
Greg Stark writes:
> I wonder whether an earlier more general proposal could have some
> leverage here though: some way to indicate that the transaction has
> taken all the locks it plans to take already. This was originally
> proposed as a way for vacuum to know it can ignore the snapshots of a
>
On Jul 11, 2009, at 6:50 AM, Greg Stark wrote:
On Sat, Jul 11, 2009 at 6:17 AM, Theo Schlossnagle
wrote:
On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
Theo Schlossnagle writes:
I would think it would be txns that would be reading that table,
but
I'm thinking it is a bit to aggressive
On Sat, Jul 11, 2009 at 6:17 AM, Theo Schlossnagle wrote:
>
>
> On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
>
>> Theo Schlossnagle writes:
>>>
>>> I would think it would be txns that would be reading that table, but
>>> I'm thinking it is a bit to aggressive. Am I reading the code wrong
>>> the
On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
Theo Schlossnagle writes:
I would think it would be txns that would be reading that table, but
I'm thinking it is a bit to aggressive. Am I reading the code wrong
there? I'm thinking it should be more selective about vxids it
chooses to block o
Theo Schlossnagle writes:
> I would think it would be txns that would be reading that table, but
> I'm thinking it is a bit to aggressive. Am I reading the code wrong
> there? I'm thinking it should be more selective about vxids it
> chooses to block on. I'd expect it to block on vxids to
We just ran into a case where we were performing two concurrent index
builds on two different tables in two different schemas in the same
database (no relational constraints between them).
One of the index builds locked on the other.
The first index build started...
The second index build st
12 matches
Mail list logo
