On Fri, Feb 3, 2012 at 10:28 AM, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs wrote:
>> On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut wrote:
>>> On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
Patch now locks index in AccessExclusiveLock in final stage of drop.
On Sun, Jan 8, 2012 at 8:19 AM, Simon Riggs wrote:
> On Wed, Jan 4, 2012 at 11:14 AM, Simon Riggs wrote:
>
>> Not having a freelist at all is probably a simpler way of avoiding the
>> lock contention, so I'll happily back that suggestion instead. Patch
>> attached, previous patch revoked.
>
> v2
On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs wrote:
> On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut wrote:
>> On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
>>> Patch now locks index in AccessExclusiveLock in final stage of drop.
>>
>> Doesn't that defeat the point of doing the CONCURREN
On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut wrote:
> On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
>> Patch now locks index in AccessExclusiveLock in final stage of drop.
>
> Doesn't that defeat the point of doing the CONCURRENTLY business in the
> first place?
That was my initial re
On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
> Patch now locks index in AccessExclusiveLock in final stage of drop.
Doesn't that defeat the point of doing the CONCURRENTLY business in the
first place?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Feb 1, 2012 at 2:56 AM, Robert Haas wrote:
> I improved the grammar issues in the attached version of the patch -
> the syntax is now simpler and more consistent, IF EXISTS now works,
> and RESTRICT is accepted (without changing the behavior) while CASCADE
> fails with a nicer error messa
On Sun, Jan 29, 2012 at 5:01 PM, Simon Riggs wrote:
> I can't see any way that situation can occur. The patch *explicitly*
> waits until all people that can see the index as usable have dropped
> their lock. So I don't think this is necessary. Having said that,
> since we are talking about the ind
On Thu, Jan 26, 2012 at 2:25 AM, Robert Haas wrote:
> On Sat, Jan 21, 2012 at 10:11 AM, Simon Riggs wrote:
>> Your caution is wise. All users of an index have already checked
>> whether the index is usable at plan time, so although there is much
>> code that assumes they can look at the index its
On Sat, Jan 21, 2012 at 10:11 AM, Simon Riggs wrote:
> Your caution is wise. All users of an index have already checked
> whether the index is usable at plan time, so although there is much
> code that assumes they can look at the index itself, that is not
> executed until after the correct checks
On Mon, Jan 23, 2012 at 4:01 PM, Tom Lane wrote:
> The real
> problem there is that BufFreelistLock is also used to protect the
> clock sweep pointer.
Agreed
> I think basically we gotta find a way to allow
> multiple backends to run clock sweeps concurrently. Or else fix
> things so that the
On Mon, Jan 23, 2012 at 5:06 AM, Robert Haas wrote:
> On Mon, Jan 23, 2012 at 12:12 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sat, Jan 21, 2012 at 5:29 PM, Jim Nasby wrote:
We should also look at having the freelist do something useful, instead of
just dropping it completely.
On Sat, Jan 21, 2012 at 2:29 PM, Jim Nasby wrote:
> On Jan 20, 2012, at 11:54 AM, Heikki Linnakangas wrote:
>> So, you're proposing that we remove freelist altogether? Sounds reasonable,
>> but that needs to be performance tested somehow. I'm not sure what exactly
>> the test should look like,
On Mon, Jan 23, 2012 at 11:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 23, 2012 at 12:12 AM, Tom Lane wrote:
The expensive part of what
we do while holding BufFreelistLock is, I think, iterating through
buffers taking and releasing a spinlock on each one (!).
>
>>>
Robert Haas writes:
> On Mon, Jan 23, 2012 at 12:12 AM, Tom Lane wrote:
>>> The expensive part of what
>>> we do while holding BufFreelistLock is, I think, iterating through
>>> buffers taking and releasing a spinlock on each one (!).
>> Yeah ... spinlocks that, by definition, will be unconteste
On Mon, Jan 23, 2012 at 1:06 PM, Robert Haas wrote:
> It's pretty trivial to prove that there is a very serious problem with
> BufFreelistLock. I'll admit I can't prove what the right fix is just
> yet, and certainly measurement is warranted.
I agree there is a problem with BufFreelistLock (so
On Mon, Jan 23, 2012 at 12:12 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 21, 2012 at 5:29 PM, Jim Nasby wrote:
>>> We should also look at having the freelist do something useful, instead of
>>> just dropping it completely. Unfortunately that's probably more work...
>
>> That's kin
Robert Haas writes:
> On Sat, Jan 21, 2012 at 5:29 PM, Jim Nasby wrote:
>> We should also look at having the freelist do something useful, instead of
>> just dropping it completely. Unfortunately that's probably more work...
> That's kinda my feeling as well. The free list in its current form
On Sat, Jan 21, 2012 at 5:29 PM, Jim Nasby wrote:
> We should also look at having the freelist do something useful, instead of
> just dropping it completely. Unfortunately that's probably more work...
That's kinda my feeling as well. The free list in its current form is
pretty much useless, but
On Jan 20, 2012, at 11:54 AM, Heikki Linnakangas wrote:
> On 04.01.2012 13:14, Simon Riggs wrote:
>> On Tue, Jan 3, 2012 at 11:28 PM, Tom Lane wrote:
>>> Jim Nasby writes:
On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
> This could well be related to the fact that DropRelFileNodeBuffers
On Sat, Jan 21, 2012 at 1:53 AM, Robert Haas wrote:
> On Thu, Jan 19, 2012 at 10:02 AM, Simon Riggs wrote:
>> On Wed, Jan 18, 2012 at 11:12 PM, Robert Haas wrote:
>>> On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs wrote:
Can I just check with you that the only review comment is a one line
>>
On Thu, Jan 19, 2012 at 10:02 AM, Simon Riggs wrote:
> On Wed, Jan 18, 2012 at 11:12 PM, Robert Haas wrote:
>> On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs wrote:
>>> Can I just check with you that the only review comment is a one line
>>> change? Seems better to make any additional review comme
On 04.01.2012 13:14, Simon Riggs wrote:
On Tue, Jan 3, 2012 at 11:28 PM, Tom Lane wrote:
Jim Nasby writes:
On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
This could well be related to the fact that DropRelFileNodeBuffers()
does a scan of shared_buffers, which is an O(N) approach no matter t
On Wed, Jan 18, 2012 at 11:12 PM, Robert Haas wrote:
> On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs wrote:
>> Can I just check with you that the only review comment is a one line
>> change? Seems better to make any additional review comments in one go.
>
> No, I haven't done a full review yet - I
On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs wrote:
> Can I just check with you that the only review comment is a one line
> change? Seems better to make any additional review comments in one go.
No, I haven't done a full review yet - I just noticed that right at
the outset and wanted to be sure
On Wed, Jan 18, 2012 at 1:28 AM, Robert Haas wrote:
> On Tue, Jan 17, 2012 at 12:06 PM, Peter Eisentraut wrote:
>> On mån, 2012-01-16 at 14:46 -0500, Robert Haas wrote:
>>> On Mon, Jan 16, 2012 at 2:06 PM, Peter Eisentraut wrote:
>>> > On mån, 2012-01-16 at 11:17 -0500, Robert Haas wrote:
>>> >>
On Tue, Jan 17, 2012 at 12:06 PM, Peter Eisentraut wrote:
> On mån, 2012-01-16 at 14:46 -0500, Robert Haas wrote:
>> On Mon, Jan 16, 2012 at 2:06 PM, Peter Eisentraut wrote:
>> > On mån, 2012-01-16 at 11:17 -0500, Robert Haas wrote:
>> >> I don't see how setting indisvalid to false helps with thi
On mån, 2012-01-16 at 14:46 -0500, Robert Haas wrote:
> On Mon, Jan 16, 2012 at 2:06 PM, Peter Eisentraut wrote:
> > On mån, 2012-01-16 at 11:17 -0500, Robert Haas wrote:
> >> I don't see how setting indisvalid to false helps with this, because
> >> IIUC when a session sees indisvalid = false, it
On Mon, Jan 16, 2012 at 2:06 PM, Peter Eisentraut wrote:
> On mån, 2012-01-16 at 11:17 -0500, Robert Haas wrote:
>> I don't see how setting indisvalid to false helps with this, because
>> IIUC when a session sees indisvalid = false, it is supposed to avoid
>> using the index for queries but still
On mån, 2012-01-16 at 11:17 -0500, Robert Haas wrote:
> I don't see how setting indisvalid to false helps with this, because
> IIUC when a session sees indisvalid = false, it is supposed to avoid
> using the index for queries but still make new index entries when a
> write operation happens - but t
On Sat, Dec 31, 2011 at 8:26 AM, Simon Riggs wrote:
> On Fri, Dec 30, 2011 at 10:20 PM, Peter Eisentraut wrote:
>> On ons, 2011-08-24 at 11:24 -0700, Daniel Farina wrote:
>>> I was poking around at tablecmds and index.c and wonder if a similar
>>> two-pass approach as used by CREATE INDEX CONCURR
On Wed, Jan 4, 2012 at 11:14 AM, Simon Riggs wrote:
> Not having a freelist at all is probably a simpler way of avoiding the
> lock contention, so I'll happily back that suggestion instead. Patch
> attached, previous patch revoked.
v2 attached with cleanup of some random stuff that crept onto pa
On Tue, Jan 3, 2012 at 11:28 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
>>> This could well be related to the fact that DropRelFileNodeBuffers()
>>> does a scan of shared_buffers, which is an O(N) approach no matter the
>>> size of the index.
>
>> C
On Jan 3, 2012, at 7:34 PM, Robert Haas wrote:
> On Tue, Jan 3, 2012 at 7:11 PM, Tom Lane wrote:
>> Jim Nasby writes:
>>> Yeah, but the problem we run into is that with every backend trying to run
>>> the clock on it's own we end up with high contention again... it's just in
>>> a different pla
On Tue, Jan 3, 2012 at 7:11 PM, Tom Lane wrote:
> Jim Nasby writes:
>> Yeah, but the problem we run into is that with every backend trying to run
>> the clock on it's own we end up with high contention again... it's just in a
>> different place than when we had a true LRU. The clock sweep might
Jim Nasby writes:
> Yeah, but the problem we run into is that with every backend trying to run
> the clock on it's own we end up with high contention again... it's just in a
> different place than when we had a true LRU. The clock sweep might be cheaper
> than the linked list was, but it's stil
On Jan 3, 2012, at 5:28 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
>>> This could well be related to the fact that DropRelFileNodeBuffers()
>>> does a scan of shared_buffers, which is an O(N) approach no matter the
>>> size of the index.
>
>> Couldn
Jim Nasby writes:
> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
>> This could well be related to the fact that DropRelFileNodeBuffers()
>> does a scan of shared_buffers, which is an O(N) approach no matter the
>> size of the index.
> Couldn't we just leave the buffers alone? Once an index is
On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
> This could well be related to the fact that DropRelFileNodeBuffers()
> does a scan of shared_buffers, which is an O(N) approach no matter the
> size of the index.
>
> On top of that, taking what Robert Haas mentioned on another thread,
> Invalidate
On Fri, Sep 9, 2011 at 11:02 PM, Daniel Farina wrote:
> On Wed, Aug 24, 2011 at 1:04 PM, Daniel Farina wrote:
>> On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
>>> Assuming the issue really is the physical unlinks (which I agree I'd
>>> like to see some evidence for), I wonder whether the pro
On Fri, Dec 30, 2011 at 10:20 PM, Peter Eisentraut wrote:
> On ons, 2011-08-24 at 11:24 -0700, Daniel Farina wrote:
>> I was poking around at tablecmds and index.c and wonder if a similar
>> two-pass approach as used by CREATE INDEX CONCURRENTLY can be used to
>> create a DROP INDEX CONCURRENTLY,
On ons, 2011-08-24 at 11:24 -0700, Daniel Farina wrote:
> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
> recently when frobbing around some indexes I realized that there is no
> equivalent for DROP INDEX, and this is a similar but lesser problem
> (as CREATE INDEX takes much l
On Wed, Aug 24, 2011 at 1:04 PM, Daniel Farina wrote:
> On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
>> Assuming the issue really is the physical unlinks (which I agree I'd
>> like to see some evidence for), I wonder whether the problem could be
>> addressed by moving smgrDoPendingDeletes()
On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina wrote:
>>> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
>>> recently when frobbing around some indexes I realized that there is no
>>> equivalent for
Merlin Moncure writes:
> On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina wrote:
>> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
>> recently when frobbing around some indexes I realized that there is no
>> equivalent for DROP INDEX, and this is a similar but lesser problem
>>
On Wed, Aug 24, 2011 at 2:24 PM, Daniel Farina wrote:
> Could I make the ACCESS EXCLUSIVE section just long enough to commit
> catalog updates, and then have the bulk of the work happen afterwards?
>
> The general idea is:
>
> 1) set an index as "invalid", to ensure no backend will use it in plann
On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina wrote:
> Hello list,
>
> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
> recently when frobbing around some indexes I realized that there is no
> equivalent for DROP INDEX, and this is a similar but lesser problem
> (as CREATE IND
46 matches
Mail list logo
