On Tue, Jan 30, 2024 at 10:33 AM Richard Guo wrote:
> Attached is an updated patch. Nothing else has changed.
>
Here is another rebase over master so it applies again. Nothing else
has changed.
Thanks
Richard
v7-0001-Support-run-time-partition-pruning-for-hash-join.patch
Description:
On Sat, Jan 27, 2024 at 11:29 AM vignesh C wrote:
> CFBot shows that the patch does not apply anymore as in [1]:
>
> Please post an updated version for the same.
Attached is an updated patch. Nothing else has changed.
Thanks
Richard
On Tue, 7 Nov 2023 at 13:25, Richard Guo wrote:
>
>
> On Mon, Nov 6, 2023 at 11:00 PM Alexander Lakhin wrote:
>>
>> Please look at a warning and an assertion failure triggered by the
>> following script:
>> set parallel_setup_cost = 0;
>> set parallel_tuple_cost = 0;
>> set
On Mon, Nov 6, 2023 at 11:00 PM Alexander Lakhin
wrote:
> Please look at a warning and an assertion failure triggered by the
> following script:
> set parallel_setup_cost = 0;
> set parallel_tuple_cost = 0;
> set min_parallel_table_scan_size = '1kB';
>
> create table t1 (i int) partition by
Hello Richard,
06.11.2023 06:05, Richard Guo wrote:
Fixed this issue in v4.
Please look at a warning and an assertion failure triggered by the
following script:
set parallel_setup_cost = 0;
set parallel_tuple_cost = 0;
set min_parallel_table_scan_size = '1kB';
create table t1 (i int)
On Sat, Nov 4, 2023 at 6:00 PM Alexander Lakhin wrote:
> 02.11.2023 14:19, Richard Guo wrote:
>
> However, the cfbot indicates that there are test cases that fail on
> FreeBSD [1] (no failure on other platforms). So I set up a FreeBSD-13
> locally but just cannot reproduce the failure. I must
Hello Richard,
02.11.2023 14:19, Richard Guo wrote:
However, the cfbot indicates that there are test cases that fail on
FreeBSD [1] (no failure on other platforms). So I set up a FreeBSD-13
locally but just cannot reproduce the failure. I must be doing
something wrong. Can anyone give me
On Tue, Aug 29, 2023 at 6:41 PM Richard Guo wrote:
> So it seems that the new costing logic is quite crude and tends to be
> very conservative, but it can help avoid the large overhead in the worst
> cases. I think this might be a good start to push this patch forward.
>
> Any thoughts or
On Fri, Aug 25, 2023 at 11:03 AM David Rowley wrote:
> I'd suggest writing some cost which costs an execution of run-time
> pruning. With LIST and RANGE you probably want something like
> cpu_operator_cost * LOG2(nparts) once for each hashed tuple to account
> for the binary search over the
On Fri, Aug 25, 2023 at 11:03 AM David Rowley wrote:
> On Thu, 24 Aug 2023 at 21:27, Richard Guo wrote:
> > I think we need to solve this problem first before we can
> > make this new partition pruning mechanism some useful in practice, but
> > how? Some thoughts currently in my mind include
>
On Thu, 24 Aug 2023 at 21:27, Richard Guo wrote:
> I performed some performance comparisons of the worst case with two
> tables as below:
>
> 1. The partitioned table has 1000 children, and 100,000 tuples in total.
>
> 2. The other table is designed that
> a) its tuples occupy every partition
On Tue, Aug 22, 2023 at 2:38 PM David Rowley wrote:
> It would be good to see some performance comparisons of the worst case
> to see how much overhead the pruning code adds to Hash Join. It may
> well be that we need to consider two Hash Join paths, one with and one
> without run-time pruning.
>
> > fwiw, the current master totally ignores the cost reduction for run-time
> > partition prune, even for init partition prune. So in some real cases,
> > pg chooses a hash join just because the cost of nest loop join is
> > highly over estimated.
>
> This is true about the existing code. It's
On Tue, Aug 22, 2023 at 5:43 PM Richard Guo wrote:
>
> On Mon, Aug 21, 2023 at 8:34 PM Andy Fan wrote:
>
>> This feature looks good, but is it possible to know if we can prune
>> any subnodes before we pay the extra effort (building the Hash
>> table, for each row... stuff)?
>>
>
> It might be
On Tue, Aug 22, 2023 at 2:38 PM David Rowley wrote:
> With Hash Join, it seems to me that the pruning must take place for
> every row that makes it into the hash table. There will be maybe
> cases where the unioned set of partitions simply yields every
> partition and all the work results in no
On Mon, Aug 21, 2023 at 8:34 PM Andy Fan wrote:
> This feature looks good, but is it possible to know if we can prune
> any subnodes before we pay the extra effort (building the Hash
> table, for each row... stuff)?
>
It might be possible if we take the partition prunning into
consideration
On Tue, 22 Aug 2023 at 00:34, Andy Fan wrote:
>
> On Mon, Aug 21, 2023 at 11:48 AM Richard Guo wrote:
>> 1. All the join partition prunning decisions are made in createplan.c
>>where the best path tree has been decided. This is not great. Maybe
>>it's better to make it happen when we
On Mon, Aug 21, 2023 at 11:48 AM Richard Guo wrote:
> If we have a hash join with an Append node on the outer side, something
> like
>
> Hash Join
>Hash Cond: (pt.a = t.a)
>-> Append
> -> Seq Scan on pt_p1 pt_1
> -> Seq Scan on pt_p2 pt_2
> -> Seq Scan on
If we have a hash join with an Append node on the outer side, something
like
Hash Join
Hash Cond: (pt.a = t.a)
-> Append
-> Seq Scan on pt_p1 pt_1
-> Seq Scan on pt_p2 pt_2
-> Seq Scan on pt_p3 pt_3
-> Hash
-> Seq Scan on t
We can actually
19 matches
Mail list logo
