Обсуждение: BUG #17153: tpch-hammerdb-Query21
The following bug has been logged on the website: Bug reference: 17153 Logged by: bommareddy Email address: anilbommareddy09@gmail.com PostgreSQL version: 13.3 Operating system: RHEL8.3 Description: In PostgreSQL13.3 , tried to run tpch with Hammedb benchmark environment . Observed Q17,Q20, Q21 executed long period time . Q17--->5000 seconds Q20--->6124 seconds Q21--->53271 seconds. the issue was may not observe with pervious/older PostgreSQL version like 12.x Run the following commands in sequence to load data Hammerdb4.x]./hammerdbcli >dbset db pg #Configure the database type. >dbset bm tpc-h #Configure the test model. >diset connection pg_host localhost #Configure the database service address. >diset tpch pg_tpch_superuser gpadmin #Configures the database superuser. >diset tpch pg_tpch_superuserpass 123456 #Configures the database superuser password. >diset tpch pg_tpch_defaultdbase postgres #Configures the default superuser database >diset tpch pg_scale_fact 1 #Configure data volume. The default value is 1. >diset tpch pg_num_tpch_threads 30 #Configure the number of concurrent threads. >diset tpch pg_tpch_gpcompat true #Enable Greenplum-compatibility. >diset tpch pg_tpch_gpcompress true #Enable Greenplum parameters. >buildschema "ALL VIRTUAL USERS COMPLETE" is returned, indicating that the data is imported successfully. Perform the test. in hammerdbcli >vuset vu 1 #Configure the number of concurrent tasks. >vuset showoutput 1 #Enable the log function. >vuset logtotemp 1 #Enable the function of automatically saving logs to the /tmp directory. >vuset unique 1 #Configure log uniqueness, that is, logs are not overwritten. >print vuconf ##View the task configuration Create a database on the database server and create a table based on the test model. You can view the OLAP test script in "src/postgresql/pgolap.tcl" in the HammerDB installation path
On Wed, 18 Aug 2021 at 19:12, PG Bug reporting form <noreply@postgresql.org> wrote: > In PostgreSQL13.3 , tried to run tpch with Hammedb benchmark environment . > Observed Q17,Q20, Q21 executed long period time . > Q17--->5000 seconds > Q20--->6124 seconds > Q21--->53271 seconds. > the issue was may not observe with pervious/older PostgreSQL version like > 12.x There's really not much to go on here. We'd need much more detail than you've provided to be able to identify if there are any bugs. How long did those queries take to run in v12? We'd also need: * EXPLAIN ANALYZE output for each query on each version * postgresql.conf from each version. * schema from each version. David
also they have added these lines in pgolap.tcl
set sql(17) "CREATE INDEX LINEITEM_PART_SUPP_FKIDX ON LINEITEM (L_PARTKEY,| -------------------------------------------------------------------------
set sql(18) "CREATE INDEX ORDER_CUSTOMER_FKIDX ON ORDERS (O_CUSTKEY)" | -------------------------------------------------------------------------
set sql(19) "CREATE INDEX PARTSUPP_PART_FKIDX ON PARTSUPP (PS_PARTKEY)" | -------------------------------------------------------------------------
set sql(20) "CREATE INDEX PARTSUPP_SUPPLIER_FKIDX ON PARTSUPP (PS_SUPPKEY)| -------------------------------------------------------------------------
set sql(21) "CREATE INDEX SUPPLIER_NATION_FKIDX ON SUPPLIER (S_NATIONKEY)"| -------------------------------------------------------------------------
set sql(22) "CREATE INDEX CUSTOMER_NATION_FKIDX ON CUSTOMER (C_NATIONKEY)"| -------------------------------------------------------------------------
set sql(23) "CREATE INDEX NATION_REGIONKEY_FKIDX ON NATION (N_REGIONKEY)" | -------------------------------------------------------------------------
set sql(24)
In the older version HammerDB4.0 ,Indexes are not created when running Postgres TPCH
On 18-Aug-2021, at 3:49 PM, David Rowley <dgrowleyml@gmail.com> wrote:
On Wed, 18 Aug 2021 at 19:12, PG Bug reporting form
<noreply@postgresql.org> wrote:In PostgreSQL13.3 , tried to run tpch with Hammedb benchmark environment .Observed Q17,Q20, Q21 executed long period time .Q17--->5000 secondsQ20--->6124 secondsQ21--->53271 seconds.the issue was may not observe with pervious/older PostgreSQL version like12.x
There's really not much to go on here. We'd need much more detail than
you've provided to be able to identify if there are any bugs.
How long did those queries take to run in v12?
We'd also need:
* EXPLAIN ANALYZE output for each query on each version
* postgresql.conf from each version.
* schema from each version.
David