On Tue, Jan 19, 2016 at 4:49 PM, Tomas Vondra
wrote:
> I can totally see why this would slow-down the BuildBuckets function, but I
> don't quite see why it should make the other code significantly slower. Yet
> BuildBuckets takes just ~25ms while the total duration increases by ~200ms
> (for the 1
On 01/19/2016 08:34 PM, Robert Haas wrote:
On Mon, Jan 18, 2016 at 10:57 PM, Tomas Vondra
wrote:
If this doesn't regress performance in the case where the number of
buckets is estimated accurately to begin with, then I think this is
a great idea. Can you supply some performance tests results
On Mon, Jan 18, 2016 at 10:57 PM, Tomas Vondra
wrote:
>>> If this doesn't regress performance in the case where the number of
>>> buckets is estimated accurately to begin with, then I think this is
>>> a great idea. Can you supply some performance tests results for that
>>> case, and maybe some of
Hi,
On 12/17/2015 10:28 PM, Tomas Vondra wrote:
Hi,
On 12/17/2015 07:20 PM, Robert Haas wrote:
...
If this doesn't regress performance in the case where the number of
buckets is estimated accurately to begin with, then I think this is
a great idea. Can you supply some performance tests result
Hi,
attached is v2 of the patch, with a bugfix and two significant improvements:
1) bugfix: forgotten memset() in ExecHashIncreaseNumBatches()
Caused segfaults whenever we started with a single batch and then
had to increase the number of batches.
2) 0002: postpone the batching (not just
Hi,
On 12/17/2015 07:20 PM, Robert Haas wrote:
...
If this doesn't regress performance in the case where the number of
buckets is estimated accurately to begin with, then I think this is
a great idea. Can you supply some performance tests results for that
case, and maybe some of the other cases
On Mon, Dec 14, 2015 at 3:04 PM, Tomas Vondra
wrote:
> attached is v1 of one of the hashjoin improvements mentioned in September in
> the lengthy thread [1].
>
> The main objection against simply removing the MaxAllocSize check (and
> switching to MemoryContextAllocHuge) is that if the number of r
Hi,
attached is v1 of one of the hashjoin improvements mentioned in
September in the lengthy thread [1].
The main objection against simply removing the MaxAllocSize check (and
switching to MemoryContextAllocHuge) is that if the number of rows is
overestimated, we may consume significantly mo
