On Thu, Mar 21, 2019 at 02:22:40AM +0100, Tomas Vondra wrote:
...
OK, so here is a bit more polished version of the dlist-based patch.
It's almost identical to what I posted before, except that it:
1) undoes the non-working optimization in DropRelationFiles()
2) removes add_to_unowned_list/re
On 3/12/19 11:54 PM, Tomas Vondra wrote:
>
>
> On 3/10/19 9:09 PM, Alvaro Herrera wrote:
>> On 2019-Feb-07, Tomas Vondra wrote:
>>
>>> Attached is a WIP patch removing the optimization from DropRelationFiles
>>> and adding it to smgrDoPendingDeletes. This resolves the issue, at least
>>> in the c
On Wed, Mar 13, 2019 at 9:47 AM Tomas Vondra
wrote:
> AFAICS we already maintain a hash table of the smgr relations, and we
> look them up in this table. We don't need to look them up in the list of
> unowned relations - the whole problem is that with the current
> single-linked list, we need to i
On 3/13/19 1:12 PM, Robert Haas wrote:
> On Tue, Mar 12, 2019 at 6:54 PM Tomas Vondra
> wrote:
>> Attached is a patch adopting the dlist approach - it seems to be working
>> quite fine, and is a bit cleaner than just slapping another pointer into
>> the SMgrRelationData struct. So I'd say this is
On Tue, Mar 12, 2019 at 6:54 PM Tomas Vondra
wrote:
> Attached is a patch adopting the dlist approach - it seems to be working
> quite fine, and is a bit cleaner than just slapping another pointer into
> the SMgrRelationData struct. So I'd say this is the way to go.
What about using a data struct
On 3/10/19 9:09 PM, Alvaro Herrera wrote:
> On 2019-Feb-07, Tomas Vondra wrote:
>
>> Attached is a WIP patch removing the optimization from DropRelationFiles
>> and adding it to smgrDoPendingDeletes. This resolves the issue, at least
>> in the cases I've been able to reproduce. But maybe we shou
On 2019-Feb-07, Tomas Vondra wrote:
> Attached is a WIP patch removing the optimization from DropRelationFiles
> and adding it to smgrDoPendingDeletes. This resolves the issue, at least
> in the cases I've been able to reproduce. But maybe we should deal with
> this issue earlier by ensuring the t
On 3/6/19 8:04 PM, Robert Haas wrote:
> On Wed, Mar 6, 2019 at 1:53 PM Alvaro Herrera
> wrote:
>> On 2019-Feb-08, Tomas Vondra wrote:
>>> I'm wondering if we should just get rid of all such optimizations, and
>>> make the unowned list doubly-linked (WIP patch attached, needs fixing
>>> the commen
On 3/6/19 7:52 PM, Alvaro Herrera wrote:
> On 2019-Feb-08, Tomas Vondra wrote:
>
>> I'm wondering if we should just get rid of all such optimizations, and
>> make the unowned list doubly-linked (WIP patch attached, needs fixing
>> the comments etc.).
>
> +1 for that approach.
>
> Did you cons
On Wed, Mar 6, 2019 at 1:53 PM Alvaro Herrera wrote:
> On 2019-Feb-08, Tomas Vondra wrote:
> > I'm wondering if we should just get rid of all such optimizations, and
> > make the unowned list doubly-linked (WIP patch attached, needs fixing
> > the comments etc.).
>
> +1 for that approach.
+1 for
On 2019-Feb-08, Tomas Vondra wrote:
> I'm wondering if we should just get rid of all such optimizations, and
> make the unowned list doubly-linked (WIP patch attached, needs fixing
> the comments etc.).
+1 for that approach.
Did you consider using a dlist?
--
Álvaro Herrerahttp
On 2/8/19 2:27 PM, Tomas Vondra wrote:
>
>
>
> On 2/8/19 12:32 PM, Ideriha, Takeshi wrote:
>>> From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
>>> But it's a bit funnier, because there's also DropRelationFiles() which does
>>> smgrclose on
>>> a batch of relations too, and it says this
On 2/8/19 12:32 PM, Ideriha, Takeshi wrote:
>> From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
>> But it's a bit funnier, because there's also DropRelationFiles() which does
>> smgrclose on
>> a batch of relations too, and it says this
>>
>>/*
>> * Call smgrclose() in reverse o
>From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
>But it's a bit funnier, because there's also DropRelationFiles() which does
>smgrclose on
>a batch of relations too, and it says this
>
>/*
> * Call smgrclose() in reverse order as when smgropen() is called.
> * This trick enab
14 matches
Mail list logo