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
The issue resolved with the latest HammerDBv4.2(HammerDB-4.2/src/postgresql/pgolap.tcl)
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
Sent from my iPhone
Show quoted text
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 seconds
Q20--->6124 seconds
Q21--->53271 seconds.
the issue was may not observe with pervious/older PostgreSQL version like
12.xThere'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