[ 
https://issues.apache.org/jira/browse/FLINK-18654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jark Wu updated FLINK-18654:
----------------------------
    Description: 
In 
https://ci.apache.org/projects/flink/flink-docs-master/dev/table/connectors/jdbc.html#partitioned-scan

> Notice that scan.partition.lower-bound and scan.partition.upper-bound are 
> just used to decide the partition stride, not for filtering the rows in 
> table. So all rows in the table will be partitioned and returned.

The "not for filtering the rows in table" is not correct, actually, if 
partition bounds is defined, it only scans rows in the bound range. 

Besides, maybe it would be better to add some practice suggestion, for example, 
"If it is a batch job, I think it also doable to get the max and min value 
first before submitting the flink job."

  was:
In 
https://ci.apache.org/projects/flink/flink-docs-master/dev/table/connectors/jdbc.html#partitioned-scan

> Notice that scan.partition.lower-bound and scan.partition.upper-bound are 
> just used to decide the partition stride, not for filtering the rows in 
> table. So all rows in the table will be partitioned and returned.

The "not for filtering the rows in table" is not correct, actually, if 
partition bounds is defined, it only scans rows in the bound range. 




> Correct missleading documentation in "Partitioned Scan" section of JDBC 
> connector
> ---------------------------------------------------------------------------------
>
>                 Key: FLINK-18654
>                 URL: https://issues.apache.org/jira/browse/FLINK-18654
>             Project: Flink
>          Issue Type: New Feature
>          Components: Connectors / JDBC, Documentation
>    Affects Versions: 1.11.0
>            Reporter: Jark Wu
>            Priority: Major
>             Fix For: 1.12.0, 1.11.2
>
>
> In 
> https://ci.apache.org/projects/flink/flink-docs-master/dev/table/connectors/jdbc.html#partitioned-scan
> > Notice that scan.partition.lower-bound and scan.partition.upper-bound are 
> > just used to decide the partition stride, not for filtering the rows in 
> > table. So all rows in the table will be partitioned and returned.
> The "not for filtering the rows in table" is not correct, actually, if 
> partition bounds is defined, it only scans rows in the bound range. 
> Besides, maybe it would be better to add some practice suggestion, for 
> example, 
> "If it is a batch job, I think it also doable to get the max and min value 
> first before submitting the flink job."



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to