Hi Andres,
> Yea, it's something we should improve. Have you checked if this has
> performance impact for heap? Should we also consider planning costs?
Since the visibility map is very small, all pages of the visibility map will
usually reside in memory. The IO cost of accessing the visibilit
We directly call the heap function VM_ALL_VISIBLE in the
IndexOnlyNext function. This is not in line with the design idea of
table am. If the new storage type needs to implement index only
scan, he must hack the IndexOnlyNext function.
So this patch add a new table am 'tid_visible' to test visibil
000)i ;
analyze t_small;
analyze t_big;
set max_parallel_workers_per_gather = 0;
On Thu, Nov 28, 2019 at 5:46 PM Andy Fan wrote:
>
>
> On Fri, Nov 22, 2019 at 6:51 PM Jinbao Chen wrote:
>
>> Hi hackers,
>>
>> I have made a patch to fix the problem.
>>
>> Ad
- ((outerndistinct - innerndistinct)/outerndistinct)*
((virtualbuckets - innerndistinct)/virtualbuckets))
On Tue, Nov 19, 2019 at 5:56 PM Jinbao Chen wrote:
> I think we have the same understanding of this issue.
>
> Sometimes use smaller costs on scanning the chain in bucket like below
>
in is
hash_qual_cost.per_tuple*innerbucketsize*outer_rows*
(1 - ((outer_distinct - inner_distinct)/outer_distinct)*((buckets_num -
inner_disttinct)/buckets_num))
Do you think this assumption is reasonable?
On Tue, Nov 19, 2019 at 3:46 PM Thomas Munro wrote:
> On Mon, Nov 18, 2019 at 7:48 PM Jinbao Che
Hi Hackers,
The planner will use big table as inner table in hash join if small table
have fewer unique values.
But this plan is much slower than using small table as inner table. This
problem occurs on master
branch without parallel scan.
For example
create table t_small(a int);
create table t_
