Pith. sign in

REVIEW 3 major objections 6 minor 40 references

Efficient Row-Level Lineage Leveraging Predicate Pushdown

T0 review · 3 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that row-level lineage can be computed by pushing a row-selection predicate through a data pipeline, saving intermediate results only where pushdown loses precision.

desk verdict Predicate pushdown for lineage is a real idea, and the evaluation is strong, but the 'always precise' guarantee rests on a proof gap that needs repair before publication. read the letter →

arxiv 2412.16864 v1 pith:O52MOWRD submitted 2024-12-22 cs.DB

Yin Lin , Cong Yan This is my paper · ORCID
classification cs.DB
keywords row-levellineagepredicatepushdowndataprovenancelazyinferenceintermediateresultmaterializationsciencepipelinesTPC-H
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper's central claim is that row-level lineage can be obtained by reusing predicate pushdown, a standard query optimization. Instead of instrumenting operators or rewriting the whole query, PredTrace encodes the target output row as a row-selection predicate and pushes it down through the pipeline to the source tables, treating the selected rows as lineage. For a single operator the pushed-down predicate is claimed to select exactly the minimal input subset, and with a few saved intermediate results the same guarantee is claimed for an entire pipeline. When intermediate results cannot be saved, PredTrace still returns a lineage superset and iteratively refines it, cutting the average false-positive rate on TPC-H from 70.7% to 6.6%. The payoff is broad coverage: all 22 TPC-H queries and 70 real-world data-processing pipelines, with lineage queries answered in seconds and up to 98x faster than prior lazy lineage systems in the paper's experiments.

What carries the argument

The central object is the row-selection predicate $F_{row}(t)=(col_1=v_1 \land \dots \land col_k=v_k)$, constructed from a concrete output row. The argument rides on the predicate-pushdown equivalence $Op(G(T))=F(Op(T))$, or the relaxed $Op(G(T))\supseteq F(Op(T))$: pushing $F_{row}$ through each operator rewrites it into a source-table predicate. When pushing an arbitrary predicate $F_i$ is not equivalent to pushing a row-selection predicate, PredTrace materializes the operator's output and pushes a row-selection predicate from there; equivalence is checked on fixed-size symbolic tables with an SMT solver. When no intermediate result can be saved, row-value predicates containing sets of column values are pushed upward and then downward in an iterative refinement until the value sets reach a fixpoint, removing non-joinable rows from the lineage superset.

What would settle it

Run PredTrace on a small groupby-max pipeline whose group contains values 3, 4, and 5 and trace the output row for max = 5: if the returned lineage includes the rows with 3 or 4, the precise-lineage claim is falsified. On the no-intermediate-results variant, trace SELECT sum(R.a) FROM R WHERE R.a > (SELECT avg(S.b) FROM S); any returned R row with R.a <= avg(S.b) is a false positive that the iterative refinement claims to remove.

Watch

Extended reading notes

Core claim

The core discovery is a formal connection: if $t_o$ is an output row and $F_{row}$ is the conjunction of equalities that picks exactly $t_o$, then pushing $F_{row}$ through an operator $Op$ yields a predicate $G_{row}$ whose selected rows are the minimal input subset that can produce $t_o$. The paper proves this for a single operator and shows that for a pipeline, materializing an intermediate result precisely at the operators where pushdown fails makes the same guarantee hold for the whole pipeline. It also proves that pushing the final predicate all the way down without intermediates yields a meaningful superset, and introduces an iterative push-up/push-down refinement that eliminates most false positives. On its evaluation, the method covers all 22 TPC-H queries and 70 sampled real-world pipelines, supports user-defined functions and non-relational operators, and answers lineage queries in about 0.23 seconds on average when intermediate results are available.

Load-bearing premise

The method assumes that the external predicate-pushdown module returns the most selective predicate that selects exactly the minimal input-row set, and that having more equality conditions always means selecting fewer rows; if the module can only return a safe superset, the precise-lineage guarantee degrades to a superset.

Editorial extensions

If this is right

  • For a single operator, lineage is exactly what a pushed-down row-selection predicate selects, so lineage querying reduces to running a predicate rather than re-executing the pipeline.
  • When intermediate results are materialized at the operators where pushdown loses precision, pipeline-level lineage is exact, and the saved results can be kept small by column projection and by deferring materialization to a later, smaller output.
  • When materialization is impossible, iterative push-up/push-down refinement returns a lineage superset, with zero false positives on inner-join and semi-join-heavy workloads and an average false-positive rate of 6.6% across TPC-H in the paper's evaluation.
  • Supported pipelines include Pandas-style data science pipelines with user-defined functions, pivots, windows, grouped maps, and subqueries, not just SQL SPJA queries.
  • Logical lineage inference runs once per pipeline, independent of the data system, so lineage queries for arbitrary output rows can reuse the same pushed-down predicates without repeating the inference work.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: because the logical inference phase is system-independent and runs once per pipeline, the same technique could be exposed as a non-invasive service on any engine that already supports predicate pushdown, not only the prototype's SQL and Python front ends.
  • Beyond the paper: the precise-lineage guarantee is stated under set semantics, so duplicate output rows with identical values are traced together; adding unique row identifiers through the pipeline would extend the method to view-update-style row deletion, which the paper leaves open.
  • Beyond the paper: the push-up/push-down exchange that drives the iterative refinement could be reused as a general way to optimize data-debugging queries over arbitrary join graphs, since it effectively computes join-reachable row sets without materializing the full join.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper proposes PredTrace, a lazy row-level lineage inference system that constructs a row-selection predicate for a target output row and pushes it down through a data-processing pipeline using an external predicate-pushdown module (specifically MagicPush). When a non-row-selection predicate cannot be pushed down equivalently, PredTrace materializes a small intermediate result; when materialization is not feasible, it uses a push-up/iterative-refinement procedure to reduce false positives. The system is evaluated on all 22 TPC-H queries and 70 real-world Jupyter/pandas pipelines, with comparisons to Trace, GProM, Panda, and SMOKE, reporting low pipeline overhead, lineage query times around hundreds of milliseconds when intermediates are saved, and up to 10x speedups over prior lazy systems.

Significance. If the formal claims were fully established, PredTrace would be a meaningful advance: it applies lazy lineage inference to a much broader class of pipelines than prior SPJA-focused systems, including UDFs and non-relational operators, while keeping lineage querying efficient. The evaluation is broad and transparent, the system has no data-dependent free parameters, and the SMT-based verification gives reproducible, derived lineage results rather than fitted ones. The main weakness is the proof of the central 'always precise lineage' claim, which currently conflates syntactic predicate selectivity with semantic minimality and does not handle non-unique minimal lineage sets; the paper's own Table 2 shows a concrete case (GroupBy with max) where the default pushed-down predicate selects a strict superset. The iterative no-intermediate-result algorithm and its FPR evaluation are interesting, but their correctness also depends on this unproven foundation.

major comments (3)
  1. [Section 3.2, Lemma 3.1] The proof's claim that the pushed-down predicate selects the precise lineage is not established. The footnote equates 'most conjunctions' with 'most selective', but this is only syntactic: functional dependencies, disjunctions in G_row (e.g., RowExpand in Table 2), and function equalities (RowTransform) can make larger conjunction counts unrelated to row-set minimality. More importantly, Definition 3.1 defines lineage as the union of all minimal subsets when the minimal subset is not unique; a most-selective G satisfying Op(G(T)) superset of {t_o} may select only one minimal subset, or may include rows that are needed only to make the pushdown identity hold for all tables, not to produce t_o. Table 2 itself gives a counterexample: for GroupBy with max, the default G_row 'selects the entire group', a strict superset of the precise lineage. The statement that MagicPush did not fall back to this default in the experiments does not prove the formal 'always' claim, so the guarantee in contribution 1 and the decision to skip materialization in Algorithm 1 (Line 5) rest on an unproven assertion.
  2. [Section 3.2, Lemma 3.2] The proof of property (1) is invalid. It argues that any other subset of T_i that produces the target output T*_{i+1} must be a superset of T*_i, but T*_i is defined in Definition 3.1 as the union of all minimal subsets. A producing subset need not contain every minimal subset; for example, if two disjoint minimal subsets both produce the target, a third subset containing only one of them still produces the target but is not a superset of the union. Thus Lemma 3.2 does not prove that naive pushdown returns a superset of the precise lineage; it may return an incomparable set. This matters directly for Section 6, where Algorithm 3's iterative refinement is justified as reducing the size of a 'meaningful superset', and for the FPR numbers in Table 6.
  3. [Section 4.2 and Algorithm 1] The manuscript does not state precisely what property the external pushdown module must guarantee for PredTrace's correctness, nor does it formalize the decision procedure behind Algorithm 1's Line 5. The verification in Section 4.2 checks equivalence of row-exist expressions on bounded symbolic tables and asserts soundness via MagicPush's bounded-size symbolic verification, but the paper never states the resulting contract as a theorem (e.g., 'G_row is the minimal row set whose image contains t_o') nor proves that G_i equivalent to G_row implies precise lineage under Definition 3.1. Given that Table 2 lists operators for which the default G_row is a superset, the verifier can only be as strong as the property it checks; as written, the reader cannot tell whether the verifier would certify a non-minimal G_row as precise.
minor comments (6)
  1. [Section 3.2, footnote] The statement that a cardinality estimator is unnecessary because 'the predicate with the most conjunctions is the most selective' should be removed or replaced with a semantic argument; as noted in the major comments, it is not generally true.
  2. [Algorithm 2] Line 1 of Algorithm 2 contains a formatting artifact ('1 t] input :') that should be corrected.
  3. [Table 2] The default G_row entries for Pivot and UnPivot appear to be broken across lines ('col_index == v_i∧' with no continuation); the table should be reformatted so each predicate is complete and readable.
  4. [Section 4.3] The claim that a unique index implies set semantics is under-specified: a unique index makes rows distinguishable at the physical level, but PredTrace's row-selection predicates are value-based and may still treat two rows with identical projected values as indistinguishable.
  5. [Figure 4] The text in Section 7.1.2 describes Trace as iterating over input rows, while Figure 4 shows Trace as an inner join; these descriptions should be reconciled.
  6. [Section 6.1] The text refers to 'Eqn (1)' but the displayed equation is not numbered in the manuscript; adding a number or a pointer to the displayed formula would improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: PredTrace's lineage results are computed from predicate pushdown and SMT verification, not from fitted parameters or self-referential definitions.

full rationale

PredTrace's derivation chain is not circular. The core reduction—constructing a row-selection predicate F_row for a target output row, pushing it through each operator with the external module, and materializing intermediate results when pushing a non-row-selection predicate is not equivalent to pushing F_row—is executed by the algorithm and checked by SMT; no parameter is fitted to the reported lineage answers and no prediction is defined in terms of the target lineage. The only same-author dependency is MagicPush [36], cited as the external pushdown module. This is a real dependency but not a circular one: MagicPush's stated assumptions (deterministic, symbolically executable UDFs, no library functions in certain operators) do not include the target lineage result, and its search/verification output is not constructed from the lineage sets that PredTrace reports. The skeptical concern about Lemma 3.1—that syntactic conjunct count is equated with semantic minimality, and that Table 2's groupby-max default returns a superset—is a soundness/correctness gap in the proof of the 'always precise' claim, not a case where the conclusion is equivalent to the input by construction. The paper's own limitations sections explicitly acknowledge the undecidability/timeout behavior of SMT verification and residual false positives for anti-joins and non-equal semi-joins, which is consistent with an honest empirical system rather than a circular derivation. Therefore the circularity score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

No numeric free parameters are fitted to data. The approach depends on several domain assumptions inherited from MagicPush and the verification machinery, primarily the guarantee of most-selective pushdown and the generalization from symbolic tables of bounded size to arbitrary tables.

assumptions (5)
  • domain assumption The external predicate pushdown module, MagicPush, returns the most selective predicate G such that Op(G(T)) ⊇ F(Op(T)), and this G selects the precise lineage set.
    PredTrace delegates the hard part of pushdown to MagicPush [36]; the formal claim of precise lineage in Lemma 3.1 rests on this guarantee, which is not proven in this paper.
  • domain assumption Verification of predicate equivalence on fixed-size symbolic tables, e.g., two rows, generalizes to tables of any size for the supported operators and UDFs.
    Stated in Section 4.2 and borrowed from MagicPush; PredTrace uses this to decide when pushdown is precise.
  • domain assumption Tables and dataframes follow set semantics, with unique index by default, so row-selection predicates uniquely identify output rows.
    Stated in Section 4.3; this limits the approach for view updates and row deletion.
  • domain assumption The SMT solver used for verification is sound in practice, and timeouts do not compromise the results in the evaluated workloads.
    Mentioned in Section 4.2 and Section 7.1; no formal guarantee of termination or completeness.
  • standard math The lineage model from prior work [22], defining lineage as the minimal subset that can produce the output, is the right semantics for row-level lineage.
    The paper extends this model; it is a possible-causality semantics, not actual dependency, which affects applications like GDPR deletion.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Efficient Row-Level Lineage Leveraging Predicate Pushdown." pith.science (2026). https://pith.science/paper/O52MOWRD

@misc{pith2026241216864,
  author       = {Pith},
  title        = {Pith review of: Efficient Row-Level Lineage Leveraging Predicate Pushdown},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O52MOWRD}},
  note         = {Machine review of arXiv:2412.16864}
}
read the original abstract

Row-level lineage explains what input rows produce an output row through a data processing pipeline, having many applications like data debugging, auditing, data integration, etc. Prior work on lineage falls in two lines: eager lineage tracking and lazy lineage inference. Eager tracking integrates lineage tracing tightly into the operator implementation, enabling efficient customized tracking. However, this approach is intrusive, system-specific, and lacks adaptability. In contrast, lazy inference generates additional queries to compute lineage; it can be easily applied to any database, but the lineage query is usually slow. Furthermore, both approaches have limited coverage of the type of data processing pipeline supported due to operator-specific tracking or inference rules. In this work, we propose PredTrace, a lineage inference approach that achieves easy adaptation, low runtime overhead, efficient lineage querying, and high pipeline coverage. It achieves this by leveraging predicate pushdown: pushing a row-selection predicate that describes the target output down to source tables and querying the lineage by running the pushed-down predicate. PredTrace may require saving intermediate results when running the pipeline in order to compute the precise lineage. When this is not viable, it can still infer lineage but may return a superset. Compared to prior work, PredTrace achieves higher coverage on TPC-H queries as well as 70 sampled real-world data processing pipelines in which UDFs are widely used. It can infer lineage in seconds, outperforming prior lazy approaches by up to 10x.

Figures

Figures reproduced from arXiv: 2412.16864 by the authors.

Figure 1
Figure 1. Query pipeline and output result for TPC-H Q4. it does not provide precise lineage information and may result in large supersets of the actual lineage. To address this, we establish a connection between predicate pushdown and lineage tracing, demonstrating that precise lineage can be obtained when interme￾diate results are materialized. Furthermore, when materialization is not feasible, our approach significantly re… view at source ↗
Figure 2
Figure 2. Verification for non-row-selection predicate. and 𝐺 𝑜 1 with these orderkeys, and runs them on the corresponding source tables to obtain the lineage rows. 4 LINEAGE INFERENCE LEVERAGING PREDICATE PUSHDOWN 4.1 Row-selection predicate pushdown As demonstrated in Section 3.2, identifying the most selective𝐺 𝑟𝑜𝑤 when pushing down a row-selection predicate 𝐹 𝑟𝑜𝑤 is crucial for precise lineage selection. PredTrace relies … view at source ↗
Figure 3
Figure 3. Data pipeline of TPC-H Q3. and inferring precise lineage. The first type includes columns used in later operators. For instance, in the intermediate result of 𝑂𝑝4 in Q4, the o_orderpriority column is used in the GroupBy (𝑂𝑝5) and Sort (𝑂𝑝6) operations. The second type includes columns nec￾essary for equivalently pushing down 𝐹 𝑟𝑜𝑤 𝑖 , such as primary keys, join keys, and correlated columns in subqueries. As a result… view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Lineage example: baseline approaches. for SELECT clause attributes and input attributes, as well as filters for WHERE clause conditions that apply to each source table. If the minimal lineage cannot be obtained, Panda uses augmentations to encode more precise lineage i…
Figure 6
Figure 6. Figure 6: Overhead statistics (ms). Q1 Q3 Q5 Q6 Q10 Q7 Q8 Q9 Q12 Q13 Q14 Q19 Q2 Q4 Q11 Q15 Q16 Q18 Q21 Q22 Q17 Q20 0.1KB 1KB 10KB 100KB 1MB 10MB 100MB Storage Overhead PredTrace Panda [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 11
Figure 11. Figure 11: Lineage query time: with vs. without saving intermedi￾ate results. the lineage query. This time depends solely on the pipeline com￾plexity and remains unaffected by the size of the database. For all approaches, the logical lineage inference time consistently stays bel…
Figure 12
Figure 12. Figure 12: Pipeline runtime increased (log scale), lineage inference time, and lineage query time, sorted by # input rows. conditions, causing MagicPush to take longer to search and verify the correct pushed-down predicate 𝐺. The second slowest pipeline is affected by a Pivot op…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 37 canonical work pages

  1. [1]

    Monotonic query

    [n.d.]. Monotonic query. https://en.wikipedia.org/wiki/Monotonic_query

    work page

  2. [2]

    Pandas: data analysis and manipulation library in Python

    [n.d.]. Pandas: data analysis and manipulation library in Python. https://pandas. pydata.org/

    work page

  3. [3]

    The Z3 theorem prover

    [n.d.]. The Z3 theorem prover. https://github.com/Z3Prover/z3

    work page

  4. [4]

    Yael Amsterdamer, Susan B Davidson, Daniel Deutch, Tova Milo, Julia Stoy- anovich, and Val Tannen. 2011. Putting lipstick on pig: Enabling database-style workflow provenance. arXiv preprint arXiv:1201.0231 (2011)

    work page Pith review arXiv 2011

  5. [5]

    Bahareh Arab, Dieter Gawlick, Venkatesh Radhakrishnan, Hao Guo, and Boris Glavic. 2014. A generic provenance middleware for database queries, updates, and transactions

    work page 2014

  6. [6]

    Deepavali Bhagwat, Laura Chiticariu, Wang-Chiew Tan, and Gaurav Vijay- vargiya. 2005. An annotation management system for relational databases. The VLDB Journal 14 (2005), 373–396

    work page 2005

  7. [7]

    Michael Brachmann and William Spoth. 2020. Your notebook is not crumby enough, REPLace it. In Conference on Innovative Data Systems Research (CIDR)

    work page 2020

  8. [8]

    Peter Buneman, Sanjeev Khanna, and Tan Wang-Chiew. 2001. Why and where: A characterization of data provenance. In Database Theory—ICDT 2001: 8th International Conference London, UK, January 4–6, 2001 Proceedings 8 . Springer, 316–330

    work page 2001

Show all 40 references
  1. [9]

    Transaction Processing Performance Council. 1992. TPC Benchmark H (TPC-H). http://www.tpc.org/tpch/

    1992

  2. [10]

    Yingwei Cui and Jennifer Widom. 2000. Practical lineage tracing in data ware- houses. In Proceedings of 16th International Conference on Data Engineering (Cat. No. 00CB37073). IEEE, 367–378

    2000

  3. [11]

    Yingwei Cui and Jennifer Widom. 2003. Lineage tracing for general data ware- house transformations. the VLDB Journal 12, 1 (2003), 41–58

    2003

  4. [12]

    Yingwei Cui, Jennifer Widom, and Janet L Wiener. 2000. Tracing the lineage of view data in a warehousing environment. ACM Transactions on Database Systems (TODS) 25, 2 (2000), 179–227

    2000

  5. [13]

    Bailu Ding, Surajit Chaudhuri, and Vivek Narasayya. 2020. Bitvector-Aware Query Optimization for Decision Support Queries. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data . 2011–2026

    2020

  6. [14]

    Christine E Earley. 2015. Data analytics in auditing: Opportunities and challenges. Business Horizons 58, 5 (2015), 493–500

    2015

  7. [15]

    Nahum Gershon, Stephen G Eick, and Stuart Card. 1998. Information visualiza- tion. interactions 5, 2 (1998), 9–15

    1998

  8. [16]

    Boris Glavic and Gustavo Alonso. 2009. Perm: Processing provenance and data on the same data model through query rewriting. In 2009 IEEE 25th International Conference on Data Engineering . IEEE, 174–185

    2009

  9. [17]

    Boris Glavic and Gustavo Alonso. 2009. Provenance for nested subqueries. In Proceedings of the 12th International Conference on Extending Database Technology: Advances in Database Technology. 982–993

    2009

  10. [18]

    Todd J Green, Grigoris Karvounarakis, and Val Tannen. 2007. Provenance semir- ings. In Proceedings of the twenty-sixth ACM SIGMOD-SIGACT-SIGART sympo- sium on Principles of database systems . 31–40

    2007

  11. [19]

    Muhammad Ali Gulzar, Matteo Interlandi, Seunghyun Yoo, Sai Deep Tetali, Tyson Condie, Todd Millstein, and Miryung Kim. 2016. Bigdebug: Debugging primitives for interactive big data processing in spark. InProceedings of the 38th International Conference on Software Engineering ...

    2016

  12. [20]

    Joseph M Hellerstein and Michael Stonebraker. 1993. Predicate migration: Op- timizing queries with expensive predicates. In Proceedings of the 1993 ACM SIGMOD international conference on Management of data . 267–276

    1993

  13. [21]

    Daniel Hernández, Luis Galárraga, and Katja Hose. 2021. Computing how- provenance for SparQL queries via query rewriting. Proceedings of the VLDB Endowment 14, 13 (2021), 3389–3401

    2021

  14. [22]

    Robert Ikeda, Akash Das Sarma, and Jennifer Widom. 2013. Logical provenance in data-oriented workflows?. In 2013 IEEE 29th International Conference on Data Engineering (ICDE). IEEE, 877–888

    2013

  15. [23]

    Matteo Interlandi, Kshitij Shah, Sai Deep Tetali, Muhammad Ali Gulzar, Se- unghyun Yoo, Miryung Kim, Todd Millstein, and Tyson Condie. 2015. Titian: Data provenance support in spark. In Proceedings of the VLDB Endowment Inter- national Conference on Very Large Data Bases , Vol...

    2015

  16. [24]

    Srikanth Kandula, Laurel Orr, and Surajit Chaudhuri. 2019. Pushing Data-Induced Predicates through Joins in Big-Data Clusters. Proc. VLDB Endow. 13, 3 (nov 2019), 252–265

    2019

  17. [25]

    Grigoris Karvounarakis, Todd J Green, Zachary G Ives, and Val Tannen. 2013. Col- laborative data sharing via update exchange and provenance. ACM Transactions on Database Systems (TODS) 38, 3 (2013), 1–42

    2013

  18. [26]

    Maurizio Lenzerini. 2002. Data integration: A theoretical perspective. In Proceed- ings of the twenty-first ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems. 233–246

    2002

  19. [27]

    Alon Yitzchak Levy and Inderpal Singh Mumick. 1997. Query optimization by predicate move-around. US Patent 5,659,725

    1997

  20. [28]

    Alexandra Meliou, Wolfgang Gatterbauer, Katherine F Moore, and Dan Suciu

  21. [29]

    Xing Niu, Raghav Kapoor, Boris Glavic, Dieter Gawlick, Zhen Hua Liu, Vasudha Krishnaswamy, and Venkatesh Radhakrishnan. 2017. Provenance-aware query optimization. In 2017 IEEE 33rd International Conference on Data Engineering (ICDE). IEEE, 473–484

    2017

  22. [30]

    Christopher Olston, Benjamin Reed, Utkarsh Srivastava, Ravi Kumar, and Andrew Tomkins. 2008. Pig latin: a not-so-foreign language for data processing. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data. 1099–1110

    2008

  23. [31]

    Fotis Psallidas and Eugene Wu. 2018. Smoke: Fine-grained lineage at interactive speed. arXiv preprint arXiv:1801.07237 (2018)

    2018 arXiv

  24. [32]

    Nguyen Binh Truong, Kai Sun, Gyu Myoung Lee, and Yike Guo. 2019. Gdpr- compliant personal data management: A blockchain-based solution. IEEE Trans- actions on Information Forensics and Security 15 (2019), 1746–1761

    2019

  25. [33]

    Margus Veanes, Pavel Grigorenko, Peli De Halleux, and Nikolai Tillmann. 2009. Symbolic query exploration. In Formal Methods and Software Engineering: 11th International Conference on Formal Engineering Methods ICFEM 2009, Rio de Janeiro, Brazil, December 9-12, 2009. Proceeding...

    2009

  26. [34]

    Jennifer Widom. 2004. Trio: A system for integrated management of data, accuracy, and lineage. Technical Report. Stanford Infolab

    2004

  27. [35]

    Cong Yan and Yeye He. 2020. Auto-Suggest: Learning-to-Recommend Data Preparation Steps Using Data Science Notebooks. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (SIGMOD). 1539–1554

    2020

  28. [36]

    Cong Yan, Yin Lin, and Yeye He. 2023. Predicate Pushdown for Data Science Pipelines. Proceedings of the ACM on Management of Data 1, 2 (2023), 1–28

    2023

  29. [37]

    Matei Zaharia, Mosharaf Chowdhury, Michael J Franklin, Scott Shenker, Ion Stoica, et al. 2010. Spark: Cluster computing with working sets. HotCloud 10, 10-10 (2010), 95

    2010

  30. [38]

    Nan Zheng, Abdussalam Alawini, and Zachary G Ives. 2019. Fine-grained prove- nance for matching & ETL. In 2019 IEEE 35th International Conference on Data Engineering (ICDE). IEEE, 184–195

    2019

  31. [39]

    Qi Zhou, Joy Arulraj, Shamkant Navathe, William Harris, and Jinpeng Wu. 2021. Sia: Optimizing queries using learned predicates. In Proceedings of the 2021 International Conference on Management of Data . 2169–2181

    2021

  32. [2010]

    arXiv preprint arXiv:1009.2021 (2010)

    The complexity of causality and responsibility for query answers and non-answers. arXiv preprint arXiv:1009.2021 (2010)

    2010 arXiv

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.