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
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
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_
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
- ((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
>
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
