Re: [PERFORM] Performance decrease after upgrade to 9.6.1

2016-11-15 Thread Gabriela Serventi
Hi Tom! Thanks for the answer. This is just one of the benchmark that we run, we test with fewer clients and much more time, but you're right about de scale-factor, we didn't realize about that. We are going to test using your recomendations. Thanks! De: Tom

Re: [PERFORM] Some tuning suggestions on a Red Hat 6.7 - PG 9.5.3 production environment

2016-11-15 Thread Jeff Janes
On Mon, Nov 14, 2016 at 3:45 AM, Pietro Pugni wrote: > > The first issue I faced was about maintenance_work_mem because I set it to > 16GB and the server silently crashed during a VACUUM because I didn’t > consider that it could take up to autovacuum_max_workers * > maintenance_work_mem (roughly

Re: [PERFORM] Performance decrease after upgrade to 9.6.1

2016-11-15 Thread Tom Lane
Gabriela Serventi writes: > $ pgbench -l -c 100 -T 30 pgbench > starting vacuum...end. > transaction type: > scaling factor: 1 > query mode: simple > number of clients: 100 > number of threads: 1 > duration: 30 s > number of transactions actually processed: 27428 > latency average = 110.104 ms >

[PERFORM] Performance decrease after upgrade to 9.6.1

2016-11-15 Thread Gabriela Serventi
Hello! We have a server with 8.4.1 that we want to migrate to 9.6.1 Before doing anything, we ran pgbench serveral times. The results were always similar to the following: $ pgbench -l -c 100 -T 30 pgbench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 1 query mode: simpl

Re: [PERFORM] Sql Query :: Any advice ?

2016-11-15 Thread Henrik
Hi, Forex and options are in  trades table Best regards Henrik Sent from my Mi padOn vinny , Nov 15, 2016 6:46 PM wrote:Are the forex and options in the hist_account_balance table? The sequential scan is on that table so if they are, so I'm guessing they should probably by in the index.

Re: [PERFORM] Sql Query :: Any advice ?

2016-11-15 Thread vinny
Are the forex and options in the hist_account_balance table? The sequential scan is on that table so if they are, so I'm guessing they should probably by in the index. On 2016-11-15 15:30, Henrik Ekenberg wrote: Here are the indexes I have for those queries Indexes: hist_account_balance :: "h

Re: [PERFORM] Sql Query :: Any advice ?

2016-11-15 Thread Henrik Ekenberg
Here are the indexes I have for those queries Indexes: hist_account_balance  :: "hist_account_balance_ix1" btree (trade_no)     trades :: "trades_pkey" PRIMARY KEY, btree  (trade_no)  "trades_trade_date_index" btree (trade_date) //H Quoting vinny : On 2016-11-15 14:27, Henrik Ekenberg wrot

Re: [PERFORM] Sql Query :: Any advice ?

2016-11-15 Thread vinny
On 2016-11-15 14:27, Henrik Ekenberg wrote: Hi, I have some data to join and I want to get som advice from you. Any tips ? Any comments are apreciated //H select trade_no from forecast_trades.hist_account_balance left join trades using (trade_no) where trade_date > current_date - 120 and

[PERFORM] Sql Query :: Any advice ?

2016-11-15 Thread Henrik Ekenberg
Hi, I have some data to join and I want to get som advice from you. Any tips ? Any comments are apreciated //H select trade_no from forecast_trades.hist_account_balance left join trades using (trade_no) where  trade_date > current_date - 120    and    trade_date < current_date - 30    and    f

Re: [PERFORM] Query planner chooses index scan backward instead of better index option

2016-11-15 Thread Seckin Pulatkan
Thank you, Jeff for your reply. Yes, we tested with CTE as well but we are using Hibernate to generate the query and there are some more conditions that can be added if certain parameters supplied. For my knowledge, Hibernate is still not supporting CTE structures yet. That's why I will keep this