Hi folks! Me again. =/
I don't understand how query 16 works for you, and I thought I would talk through the inconsistencies I see.
Query 16 involves a join with suppliers
: it reports for each (brand, type, size) the number of distinct suppliers of such a part who have no customer complaints in their comments field. Complaints seems like sensitive information for the supplier, and if each of the counts of any parts they supply changed as a result, that could leak through. Suppliers supply exactly 80 parts each, because skew doesn't exist in TPCH it seems, which makes me think that with 0.1-DP you'll need error of magnitude at least 800.
Each part is only supplied by four suppliers (this is all at scale factor 1), and almost all (brand, type, size) triples are represented by just a few parts (2/3rds by just one) so this noise should be pretty significant, I would think. That is, 800 relative to 4.
According to your schema the supplier
relation is not public, but also there is no max_freq
for PS_SUPPKEY
in the partsupp
relation. This is where I was expecting to see 80
. Is it possible that this bound is just missing, and that when absent the analysis is overly optimistic?
Possibly related: in Query 04 you indicate in the paper that there is no join, but there is a join on orderkey
between lineitem
and orders
(count orders with late lineitems, by priority). Should this join be present too? It seems like the cardinality isn't high (in PINQ it would be a join with a distinct
applied to the order keys in late lineitems; cardinality one), but something should be there, right?
Is there a cute way you are getting around exists
and not in
fragments for these two queries?