Type: New Feature
Affects Version/s: BIGDATA_RELEASE_1_3_3
Fix Version/s: None
Component/s: Bigdata SAIL
When doing a SPARQL UPDATE, we use a CONSTRUCT under the covers.
Depending on the nature of the update this may be a triple based set or a quad based set.
The construct has a filter for distinct items.
If this is a classic construct or a triple based insert/delete then the filter is a triple based filter.
BLZG-682 concerns the support of native level filter which scales beyond a simple java hash set.
If this is a multiple named graph based insert/delete then trac
BLZG-885 concerns the need for quad based filtering rather than triple based filtering.
Both these tickets are resolved. This ticket is to do both at the same time: quad based filtering in a scalable fashion not relying on a java hash set.
As pre work, I have ensured that there are some simple tests, and that any query hints concerning native distinct support are honored to the extent that the code path which constructs the filter is aware of them.
Specifically this ticket involves implementing:
and can be tested using:
When I started writing this ticket the query hints being used in these tests were being ignored because the optimizer that noticed them was not wired up to the ASTConstructIterator class in this case. In particular the DELETE and INSERT case uses a different code path to the DELETE or INSERT cases. This is resolved, but the resolution is a least a little ugly