Andres Freund writes:
> On 2017-03-07 13:06:39 -0500, Tom Lane wrote:
>> The hashjoin issue is certainly new, and the reorderbuffer issue can't
>> go back further than 9.4. So my inclination is to patch back to 9.4
>> and call it good.
> That works for me. If we find further cases later, we can
On 2017-03-07 13:06:39 -0500, Tom Lane wrote:
> Andres Freund writes:
> >>> On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> Concretely, something like the attached. This passes regression tests
> but I've not pushed on it any harder than that.
>
> > I think we should go forward with so
Andres Freund writes:
>>> On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
Concretely, something like the attached. This passes regression tests
but I've not pushed on it any harder than that.
> I think we should go forward with something like this patch in all
> branches, and only use To
On 02/27/2017 12:55 PM, Andres Freund wrote:
On 2017-02-24 15:18:04 -0800, Andres Freund wrote:
On 2017-02-24 15:12:37 -0800, Andres Freund wrote:
On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
Concretely, something like the attached. This passes regression tests
but I've not pushed on it any
On 2017-02-27 19:20:56 +0100, Tomas Vondra wrote:
> On 02/27/2017 12:55 PM, Andres Freund wrote:
> > On 2017-02-24 15:18:04 -0800, Andres Freund wrote:
> > > On 2017-02-24 15:12:37 -0800, Andres Freund wrote:
> > > > On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> > > > > Concretely, something like
On 2017-02-24 15:18:04 -0800, Andres Freund wrote:
> On 2017-02-24 15:12:37 -0800, Andres Freund wrote:
> > On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> > > Concretely, something like the attached. This passes regression tests
> > > but I've not pushed on it any harder than that.
> >
> > Heh,
On 2017-02-24 15:12:37 -0800, Andres Freund wrote:
> On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> > Concretely, something like the attached. This passes regression tests
> > but I've not pushed on it any harder than that.
>
> Heh, I'd just gotten something that didn't immediately crash anymore
On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> Concretely, something like the attached. This passes regression tests
> but I've not pushed on it any harder than that.
Heh, I'd just gotten something that didn't immediately crash anymore ;)
Running your patch against Jeff's test-case, verified be
Jeff Janes writes:
> On Fri, Feb 24, 2017 at 10:59 AM, Tom Lane wrote:
>> Uh, what? In a doubly-linked list, you can remove an element in O(1)
>> time, you don't need any searching.
> Currently it is walking the chain to identify which block holds the chunk
> in the first place, not just to get
On Fri, Feb 24, 2017 at 10:59 AM, Tom Lane wrote:
> Jeff Janes writes:
> > On Thu, Feb 23, 2017 at 2:28 PM, Tom Lane wrote:
> >> Maybe it's time to convert that to a doubly-linked list.
>
> > I don't think that would help. You would need some heuristic to guess
> > whether the chunk you are lo
Jeff Janes writes:
> On Thu, Feb 23, 2017 at 2:28 PM, Tom Lane wrote:
>> Maybe it's time to convert that to a doubly-linked list.
> I don't think that would help. You would need some heuristic to guess
> whether the chunk you are looking for is near the front, or near the end.
Uh, what? In a
On Thu, Feb 23, 2017 at 10:47 PM, Andres Freund wrote:
> On 2017-02-23 17:28:26 -0500, Tom Lane wrote:
> > Jeff Janes writes:
> > > The number of new chunks can be almost as as large as the number of old
> > > chunks, especially if there is a very popular value. The problem is
> that
> > > ever
On Thu, Feb 23, 2017 at 2:28 PM, Tom Lane wrote:
> Jeff Janes writes:
> > The number of new chunks can be almost as as large as the number of old
> > chunks, especially if there is a very popular value. The problem is that
> > every time an old chunk is freed, the code in aset.c around line 968
On 2017-02-24 01:59:01 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-02-23 17:28:26 -0500, Tom Lane wrote:
> >> Maybe it's time to convert that to a doubly-linked list.
>
> > Yes, I do think so. Given that we only have that for full blocks, not
> > for small chunks, the cost seems neg
On Fri, Feb 24, 2017 at 12:17 PM, Andres Freund wrote:
> Jeff, do you have a handy demonstrator?
If you want to hit ExecHashIncreaseNumBatches a bunch of times, see
the "ugly" example in the attached.
--
Thomas Munro
http://www.enterprisedb.com
hj-test-queries.sql
Description: Binary data
--
Andres Freund writes:
> On 2017-02-23 17:28:26 -0500, Tom Lane wrote:
>> Maybe it's time to convert that to a doubly-linked list.
> Yes, I do think so. Given that we only have that for full blocks, not
> for small chunks, the cost seems neglegible.
> That would also, partially, address the perfor
On 2017-02-23 17:28:26 -0500, Tom Lane wrote:
> Jeff Janes writes:
> > The number of new chunks can be almost as as large as the number of old
> > chunks, especially if there is a very popular value. The problem is that
> > every time an old chunk is freed, the code in aset.c around line 968 has
Jeff Janes writes:
> The number of new chunks can be almost as as large as the number of old
> chunks, especially if there is a very popular value. The problem is that
> every time an old chunk is freed, the code in aset.c around line 968 has to
> walk over all the newly allocated chunks in the l
On Thu, Feb 23, 2017 at 2:13 PM, Jeff Janes wrote:
> Is there a good solution to this? Could the new chunks be put in a
> different memory context, and then destroy the old context and install the
> new one at the end of ExecHashIncreaseNumBatches? I couldn't find a destroy
> method for memory co
When doing a hash join with large work_mem, you can have a large number of
chunks. Then if ExecHashIncreaseNumBatches gets called, those chunks are
walked through, moving the tuples to new chunks (or to disk, if they no
longer match the batch's bitmask), and freeing the old chunks.
The number of
20 matches
Mail list logo
