abstractdog commented on PR #6758: URL: https://github.com/apache/hive/pull/6758#issuecomment-5661364917
> @abstractdog, before you invest more in the Parquet runtime: while working on the 10 TB Parquet campaign I looked closely at how ProbeDecode behaves today, and it turns out the feature has never worked end to end — for ORC either > > What ProbeDecode is meant to do At scan time, skip decoding rows whose join key is not in the map-join hash table. The planner marks the map join; the reader (per format) does the filtering. > > 1. The reader side has never filtered a row — ORC included > The only existing runtime is ORC's. Instrumented it on TPC-DS with a live probe context: 76 reader instances, 232,018 rows decoded, 0 rows filtered. > The cause is a lookup bug: LlapRecordReader.getProbeColIdx() extracts the column index by matching _col([0-9]+) against the key column name. But that name is the user's column (ss_item_sk), not _colN, so the match fails and it returns -1 on every query. With -1, the reader never filters. > So although ORC has shipped this runtime, no ORC query has ever exercised the filtering path. A Parquet runtime built on the same ProbeDecodeContext would inherit the same -1. > 2. The planner side picks the wrong join > TezCompiler chooses which map join to probe by a ratio that mixes distinct counts with row counts. With the ratio corrected, the planner selects a different join in 30 of the 81 affected golden files (in the other 51 only the ratio value changes). So today's selection is wrong roughly a third of the time. > 3. Measured end to end, it costs rather than gains > 10 TB, hive.optimize.scan.probedecode on vs off: 11.45 s vs 11.05 s — 3.7% slower with it on. Expected: the scan carries the probe plumbing and filters nothing. > > Your JMH numbers agree. The skip path pays when a selective filter is supplied (−24% decode at 10% pass, dict) and costs when it isn't (+1.2% at 90% pass). Today every scan sits at the "none" row — the lookup returns -1 — while paying the "on" overhead, which is the 3.7%. > > Once the lookup and the planner are fixed, the number that matters is a real query with a selective probe join, end to end. Decode is one slice of the scan, so −24% there is the ceiling, not the result. > > Suggestion Hold #6758 until the whole path is shown to work: pass the key column index from the plan instead of regexing a name, add a filtered-row counter to the reader, and show it nonzero on a real query. Otherwise a second runtime only adds overhead. this is currently under testing, I faced some problems too, I wasn't able to verify the perf benefits for all the queries, agree that it largely depends on filter selectivity I believe the latest code has definitely kicked in, or at least that's what I saw in Q27, see consecutive results for big table scan `Map 1` without probedecode: ``` INFO : ---------------------------------------------------------------------------------------------- INFO : VERTICES DURATION(ms) CPU_TIME(ms) GC_TIME(ms) INPUT_RECORDS OUTPUT_RECORDS INFO : ---------------------------------------------------------------------------------------------- INFO : Map 1 37482.00 0 0 5,531,934,797 1,257,998 INFO : Map 1 39497.00 0 0 5,531,934,797 1,257,998 INFO : Map 1 35966.00 0 0 5,531,934,797 1,257,998 INFO : Map 1 36981.00 0 0 5,531,934,797 1,257,998 INFO : Map 1 35947.00 0 0 5,531,934,797 1,257,998 ``` with probedecode: ``` INFO : ---------------------------------------------------------------------------------------------- INFO : VERTICES DURATION(ms) CPU_TIME(ms) GC_TIME(ms) INPUT_RECORDS OUTPUT_RECORDS INFO : ---------------------------------------------------------------------------------------------- INFO : Map 1 36945.00 0 0 686,017,131 1,257,998 INFO : Map 1 34955.00 0 0 686,017,131 1,257,998 INFO : Map 1 35952.00 0 0 686,017,131 1,257,998 INFO : Map 1 30882.00 0 0 686,017,131 1,257,998 INFO : Map 1 30928.00 0 0 686,017,131 1,257,998 INFO : Map 1 27866.00 0 0 686,017,131 1,257,998 ``` Without ProbeDecode (5 runs): 37482 + 39497 + 35966 + 36981 + 35947 = 185,873 → avg 37,174.6 ms With ProbeDecode (6 runs): 36945 + 34955 + 35952 + 30882 + 30928 + 27866 = 197,528 → avg 32,921.3 ms I have to hang on with this in favor of other low-hanging fruits, I agree that JMH doesn't reflect the possible end to end gains and regarding bugs you mentioned, let me get back to me later either -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
