functionality difference-performance postgreSQLv14-GCC-llvm-clang
Hi, PostgreSQLv14- compiled with LLVM-Clangv13 and GCCv11,And captured performance using HammerDBv4.3-TPC-H. And Observed the functionality differences as LLVM-Clangv13-triggers heapgetpage instead XidInMVCCSnapshot or vice versa with GCC. I would like to know here the functionality differences triggered i.e. function call "heapgetpage vs XidInMVCCSnapshot '' in GCC vs LLVM-Clangv13 And also observed the performance difference GCC performing (Query execution time (small value is better) better than LLVM-Clang 13 on same BareMetal with same H/W and DB configurations perf data top hot functions: LLVM-Clangv13: = TPCH-Query-completed-50.526 seconds OverheadSymbol 19.41%[.] tts_buffer_heap_getsomeattrs * 17.75%[.] heapgetpage* 9.46%[.] bpchareq 5.86%[.] ExecEvalScalarArrayOp 5.85%[.] ExecInterpExpr 4.50%[.] ReadBuffer_common 3.02%[.] heap_getnextslot GCCv11 === TPCH-Query-completed-41.593 seconds 21.13%[.] tts_buffer_heap_getsomeattrs *11.58%[.] XidInMVCCSnapshot* 10.87%[.] bpchareq 7.07%[.] ExecEvalScalarArrayOp 5.93%[.] ExecInterpExpr 5.16%[.] ReadBuffer_common 3.61%[.] heapgetpage Regards Arjun
Oracle_FDW table performance issue
Hi, I have one Oracle fdw table which is giving performance issue when joined local temp table gives performance issue. select * from oracle_fdw_table where transaction_id in ( select transaction_id from temp_table) 54 seconds. Seeing HASH SEMI JOIN in EXPLAIN PLAN. temp_table has only 74 records. select * from from oracle_fdw_table where transaction_id in ( 1,2,3,.,75)--- 23ms. Could you please help me understand this drastic behaviour change? Regards, Aditya.
Re: Oracle_FDW table performance issue
On Mon, Jul 11, 2022 at 05:38:34PM +0530, aditya desai wrote: > Hi, > I have one Oracle fdw table which is giving performance issue when joined > local temp table gives performance issue. > > select * from oracle_fdw_table where transaction_id in ( select > transaction_id from temp_table) 54 seconds. Seeing HASH SEMI JOIN in > EXPLAIN PLAN. temp_table has only 74 records. You'd have to share the plan https://wiki.postgresql.org/wiki/Slow_Query_Questions Do the tables have updated stats ?
Re: Oracle_FDW table performance issue
Hi Justin, Sorry unable to send a query plan from a closed network. Here the stats are updated on the Oracle table. It seems like when joining the local tables it is not filtering data on Oracle and bringing data to postgres. It is filtering when we actually pass the values. Regards, Aditya. On Mon, Jul 11, 2022 at 5:43 PM Justin Pryzby wrote: > On Mon, Jul 11, 2022 at 05:38:34PM +0530, aditya desai wrote: > > Hi, > > I have one Oracle fdw table which is giving performance issue when joined > > local temp table gives performance issue. > > > > select * from oracle_fdw_table where transaction_id in ( select > > transaction_id from temp_table) 54 seconds. Seeing HASH SEMI JOIN > in > > EXPLAIN PLAN. temp_table has only 74 records. > > You'd have to share the plan > > https://wiki.postgresql.org/wiki/Slow_Query_Questions > > Do the tables have updated stats ? >
Re: Oracle_FDW table performance issue
On Mon, 2022-07-11 at 17:38 +0530, aditya desai wrote: > I have one Oracle fdw table which is giving performance issue when joined > local temp table gives performance issue. > > select * from oracle_fdw_table where transaction_id in ( select > transaction_id from temp_table) > 54 seconds. Seeing HASH SEMI JOIN in EXPLAIN PLAN. temp_table has only > 74 records. > > select * from from oracle_fdw_table where transaction_id in ( > 1,2,3,.,75)--- 23ms. > > Could you please help me understand this drastic behaviour change? The first query joins a local table with a remote Oracle table. The only way for such a join to avoid fetching the whole Oracle table would be to have the foreign scan on the inner side of a nested loop join. But that would incur many round trips to Oracle and is therefore perhaps not a great plan either. In the second case, the whole IN list is shipped to the remote side. In short, the queries are quite different, and I don't think it is possible to get the first query to perform as well as the second. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
Re: Oracle_FDW table performance issue
Understood thanks!! Will try to build dynamiq query to send ids across instead of join. On Mon, Jul 11, 2022 at 8:56 PM Laurenz Albe wrote: > On Mon, 2022-07-11 at 17:38 +0530, aditya desai wrote: > > I have one Oracle fdw table which is giving performance issue when joined > > local temp table gives performance issue. > > > > select * from oracle_fdw_table where transaction_id in ( select > transaction_id from temp_table) > > 54 seconds. Seeing HASH SEMI JOIN in EXPLAIN PLAN. temp_table has > only 74 records. > > > > select * from from oracle_fdw_table where transaction_id in ( > 1,2,3,.,75)--- 23ms. > > > > Could you please help me understand this drastic behaviour change? > > The first query joins a local table with a remote Oracle table. The only > way for > such a join to avoid fetching the whole Oracle table would be to have the > foreign scan > on the inner side of a nested loop join. But that would incur many round > trips to Oracle > and is therefore perhaps not a great plan either. > > In the second case, the whole IN list is shipped to the remote side. > > In short, the queries are quite different, and I don't think it is > possible to get > the first query to perform as well as the second. > > Yours, > Laurenz Albe > -- > Cybertec | https://www.cybertec-postgresql.com >
