On Thu, 7 Jun 2012, Tom Lane wrote:
I extended the patch to also cover DropDatabaseBuffers,
FlushRelationBuffers, and FlushDatabaseBuffers, which have got the exact
same type of full-pool scan loop, and committed it.
Thanks everybody for the patches/commits.
Sergey
***
On 7 June 2012 22:54, Tom Lane wrote:
> I thought it would be a lot safer and probably a little bit quicker
> if we just split DropRelFileNodeBuffers into two routines, one for
> the specific-fork case and one for the all-forks case; and then the
> same for its main caller smgrdounlink. So I mod
I wrote:
> Simon Riggs writes:
>> Both of these, as attached up thread.
>> Simon's patch - dropallforks.v1.patch
>> Jeff's patch - DropRelFileNodeBuffers_unlock_v1.patch
>> (needs a little tidyup)
> OK, will take a look.
I didn't like dropallforks.v1.patch at all as presented, for several
reason
Jeff Janes writes:
>> On 30 May 2012 12:10, Heikki Linnakangas
>> wrote:
>>> Also, I wonder if DropRelFileNodeBuffers() could scan the pool without
>>> grabbing the spinlocks on every buffer? It could do an unlocked test first,
>>> and only grab the spinlock on buffers that need to be dropped.
>
Simon Riggs writes:
> On 7 June 2012 17:34, Tom Lane wrote:
>> Oh, I must be confused about which patch we are talking about --- I
>> thought this was in reference to some of the WIP ideas that were being
>> thrown about with respect to using lock-free access primitives. Which
>> patch are you p
On 7 June 2012 17:34, Tom Lane wrote:
> Simon Riggs writes:
>> On 7 June 2012 14:56, Tom Lane wrote:
>>> Say what? That's a performance result and proves not a damn thing about
>>> safety.
>
>> Of course not.
>
>> Based on the rationale explained in the code comments in the patch, it
>> seems l
Simon Riggs writes:
> On 7 June 2012 14:56, Tom Lane wrote:
>> Say what? That's a performance result and proves not a damn thing about
>> safety.
> Of course not.
> Based on the rationale explained in the code comments in the patch, it
> seems like a reasonable thing to me now.
> The argument
On 7 June 2012 14:56, Tom Lane wrote:
> Sergey Koposov writes:
>> On Tue, 5 Jun 2012, Simon Riggs wrote:
> Sounds less good and we'd need reasonable proof it actually did
> anything useful without being dangerous.
>
Doing an initial unlocked test speeds things up another 2.69 fold (o
Sergey Koposov writes:
> On Tue, 5 Jun 2012, Simon Riggs wrote:
Sounds less good and we'd need reasonable proof it actually did
anything useful without being dangerous.
>>> Doing an initial unlocked test speeds things up another 2.69 fold (on
>>> top of 3.55 for your patch) for me, with
On Tue, 5 Jun 2012, Simon Riggs wrote:
Sounds less good and we'd need reasonable proof it actually did
anything useful without being dangerous.
Doing an initial unlocked test speeds things up another 2.69 fold (on
top of 3.55 for your patch) for me, with 1GB of shared buffers. That
seems like
On 3 June 2012 19:07, Jeff Janes wrote:
> On Thu, May 31, 2012 at 5:04 AM, Simon Riggs wrote:
>> On 30 May 2012 12:10, Heikki Linnakangas
>> wrote:
>>
>>> Hmm, we do this in smgrDoPendingDeletes:
>>>
>>> for (i = 0; i <= MAX_FORKNUM; i++)
>>> {
>>> smgrdounlink(srel, i, false);
>>> }
>>>
On Thu, May 31, 2012 at 5:04 AM, Simon Riggs wrote:
> On 30 May 2012 12:10, Heikki Linnakangas
> wrote:
>
>> Hmm, we do this in smgrDoPendingDeletes:
>>
>> for (i = 0; i <= MAX_FORKNUM; i++)
>> {
>> smgrdounlink(srel, i, false);
>> }
>>
>> So we drop the buffers for each relation fork sepa
On 1 June 2012 12:34, Sergey Koposov wrote:
> On Fri, 1 Jun 2012, Simon Riggs wrote:
>
>>
>> Why do you have 10,000 tables and why is it important to drop them so
>> quickly?
>
>
> 1 tables are there, because that's the number of partitions. And I'm
> dropping them at the moment, because I'm d
On Fri, 1 Jun 2012, Simon Riggs wrote:
Why do you have 10,000 tables and why is it important to drop them so quickly?
1 tables are there, because that's the number of partitions. And I'm
dropping them at the moment, because I'm doing testing. So it won't be
really crucial for production.
On 31 May 2012 19:09, Sergey Koposov wrote:
> On Thu, 31 May 2012, Simon Riggs wrote:
>
>>
>> That struck me as a safe and easy optimisation. This was a problem I'd
>> been trying to optimise for 9.2, so I've written a patch that appears
>> simple and clean enough to be applied directly.
>
>
> Tha
On Thu, May 31, 2012 at 11:09 AM, Sergey Koposov wrote:
> On Thu, 31 May 2012, Simon Riggs wrote:
>
>>
>> That struck me as a safe and easy optimisation. This was a problem I'd
>> been trying to optimise for 9.2, so I've written a patch that appears
>> simple and clean enough to be applied directl
On Thu, 31 May 2012, Simon Riggs wrote:
That struck me as a safe and easy optimisation. This was a problem I'd
been trying to optimise for 9.2, so I've written a patch that appears
simple and clean enough to be applied directly.
Thanks! The patch indeed improved the timings,
The dropping of
On 30 May 2012 12:10, Heikki Linnakangas
wrote:
> Hmm, we do this in smgrDoPendingDeletes:
>
> for (i = 0; i <= MAX_FORKNUM; i++)
> {
> smgrdounlink(srel, i, false);
> }
>
> So we drop the buffers for each relation fork separately, which means that
> we scan the buffer pool four times. Rel
On Wed, May 30, 2012 at 2:10 PM, Heikki Linnakangas
wrote:
> Also, I wonder if DropRelFileNodeBuffers() could scan the pool without
> grabbing the spinlocks on every buffer? It could do an unlocked test first,
> and only grab the spinlock on buffers that need to be dropped.
The scanning of buffer
On Wed, May 30, 2012 at 4:10 AM, Heikki Linnakangas
wrote:
> On 30.05.2012 03:40, Sergey Koposov wrote:
>>
>> I was running some tests on PG9.2beta where I'm creating and dropping
>> large number of tables (~ 2).
>>
>> And I noticed that table dropping was extremely slow -- e.g. like half a
>>
On Wed, May 30, 2012 at 7:10 AM, Heikki Linnakangas
wrote:
> So we drop the buffers for each relation fork separately, which means that
> we scan the buffer pool four times. Relation forks in 8.4 introduced that
> issue, and 9.1 made it worse by adding another fork for unlogged tables.
> With some
On 30.05.2012 03:40, Sergey Koposov wrote:
I was running some tests on PG9.2beta where I'm creating and dropping
large number of tables (~ 2).
And I noticed that table dropping was extremely slow -- e.g. like half a
second per table.
...
I also stopped PG with gdb a few times and it was al
Hello,
I was running some tests on PG9.2beta where I'm creating and dropping
large number of tables (~ 2).
And I noticed that table dropping was extremely slow -- e.g. like half a
second per table.
I tried to move the table dropping into bigger transactions (100 per one
transaction) (i
23 matches
Mail list logo
