On Fri, Jan 6, 2017 at 11:06 AM, Andres Freund wrote:
> On 2017-01-06 11:01:32 -0500, Robert Haas wrote:
>> On Fri, Jan 6, 2017 at 10:43 AM, Andres Freund wrote:
>> > On 2016-12-16 09:34:31 -0800, Andres Freund wrote:
>> >> > To fix his issue, we need something like your 0001. Are you going to
>
On 2017-01-06 11:01:32 -0500, Robert Haas wrote:
> On Fri, Jan 6, 2017 at 10:43 AM, Andres Freund wrote:
> > On 2016-12-16 09:34:31 -0800, Andres Freund wrote:
> >> > To fix his issue, we need something like your 0001. Are you going to
> >> > polish that up soon here?
> >>
> >> Yes.
> >
> > I've
On Fri, Jan 6, 2017 at 10:43 AM, Andres Freund wrote:
> On 2016-12-16 09:34:31 -0800, Andres Freund wrote:
>> > To fix his issue, we need something like your 0001. Are you going to
>> > polish that up soon here?
>>
>> Yes.
>
> I've two versions of a fix for this. One of them basically increases t
On 2016-12-16 09:34:31 -0800, Andres Freund wrote:
> > To fix his issue, we need something like your 0001. Are you going to
> > polish that up soon here?
>
> Yes.
I've two versions of a fix for this. One of them basically increases the
"spread" of buckets when the density goes up too much. It doe
On 2016-12-16 10:12:42 -0500, Robert Haas wrote:
> On Wed, Dec 14, 2016 at 11:20 PM, Robert Haas wrote:
> > I've got no problem with that at all, but I want to unbreak things
> > more or less immediately and then you/we can further improve it later.
>
> Committed
Thanks. Although "Fix drastic sl
On Wed, Dec 14, 2016 at 11:20 PM, Robert Haas wrote:
> I've got no problem with that at all, but I want to unbreak things
> more or less immediately and then you/we can further improve it later.
Committed, although I realize now that doesn't fix Dilip's problem,
only my (somewhat different) probl
On Wed, Dec 14, 2016 at 10:08 PM, Andres Freund wrote:
> On 2016-12-14 22:00:45 -0500, Robert Haas wrote:
>> I took a look at Andres's patches today and saw that they can't really
>> be applied as-is, because they "temporarily" change the master's
>> ParallelWorkerNumber but have no provision for
On 2016-12-14 22:00:45 -0500, Robert Haas wrote:
> I took a look at Andres's patches today and saw that they can't really
> be applied as-is, because they "temporarily" change the master's
> ParallelWorkerNumber but have no provision for restoring it after an
> ERROR.
Yea, that's not quite right.
On Thu, Dec 8, 2016 at 5:23 PM, Robert Haas wrote:
> On Wed, Nov 23, 2016 at 3:33 AM, Andres Freund wrote:
>> On 2016-11-18 08:00:40 -0500, Robert Haas wrote:
>>> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote:
>>> > I've a working fix for this, and for a similar issue Robert found. I'm
>>
On Wed, Nov 23, 2016 at 3:33 AM, Andres Freund wrote:
> On 2016-11-18 08:00:40 -0500, Robert Haas wrote:
>> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote:
>> > I've a working fix for this, and for a similar issue Robert found. I'm
>> > still playing around with it, but basically the fix is
On Wed, Nov 23, 2016 at 2:03 PM, Andres Freund wrote:
> Here's my WIP series addressing this and related problems. With this
> we're again noticeably faster than the dynahash implementation, in both
> the case here, and the query you brought up over IM.
>
> This definitely needs some more TLC, but
On 2016-11-18 08:00:40 -0500, Robert Haas wrote:
> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote:
> > I've a working fix for this, and for a similar issue Robert found. I'm
> > still playing around with it, but basically the fix is to make the
> > growth policy a bit more adaptive.
>
> Any
On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote:
> I've a working fix for this, and for a similar issue Robert found. I'm
> still playing around with it, but basically the fix is to make the
> growth policy a bit more adaptive.
Any chance you can post a patch soon?
--
Robert Haas
Enterpris
On Wed, Nov 16, 2016 at 12:58 AM, Andres Freund wrote:
> It's not really related to lossy pages, it's just that due to deletions
> / insertions a lot more "shapes" of the hashtable are hit.
Okay..
>
> I suspect that this is with parallelism disabled? Without that the query
> ends up using a parall
Hi Dilip,
thanks for noticing that one.
On 2016-11-09 21:17:22 +0530, Dilip Kumar wrote:
> While testing bitmap performance, I have observed that some of the
> TPCH queries taking huge time in BitmapIndexScan node, when there are
> lossy pages.
It's not really related to lossy pages, it's just t
15 matches
Mail list logo