Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi Matthew,

Yeah and you said right!. I have analyzed the entire database and also
created appropriate indexes for the columns used in WHERE/JOIN clauses.

Okay I will just provide the fourth union part of the query which you can
analyze easier(this not that big).

Please find the query part. And refer to the table definitions in my
previous posts.
Query:

select 
0 as id,
header.id as header_id,
'0' as emp_id,
 0 as sno,
users.alias_id as alias,
partner.name as name,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
work_order_no != 'CORPORATE' and
res_employee_id=users.res_employee_id and date in (select date::date from
generate_series((select start_date from tms_timesheet_period where
id=127),(select end_date from tms_timesheet_period where id=127),'1
day'::interval) date)) billed_hrs,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
release_no = 'unbillable_time' and
res_employee_id=users.res_employee_id and date in (select date::date from
generate_series((select start_date from tms_timesheet_period where
id=127),(select end_date from tms_timesheet_period where id=127),'1
day'::interval) date)) as unbilled_hrs,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
release_no = 'paid_time_off' and
res_employee_id=users.res_employee_id and date in (select date::date from
generate_series((select start_date from tms_timesheet_period where
id=127),(select end_date from tms_timesheet_period where id=127),'1
day'::interval) date)) as paid_time_off,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
release_no = 'unpaid_leave' and
res_employee_id=users.res_employee_id and date in (select date::date from
generate_series((select start_date from tms_timesheet_period where
id=127),(select end_date from tms_timesheet_period where id=127),'1
day'::interval) date)) as unpaid_leave,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
release_no = 'bereavement_time' and
res_employee_id=users.res_employee_id and date in (select date::date from
generate_series((select start_date from tms_timesheet_period where
id=127),(select end_date from tms_timesheet_period where id=127),'1
day'::interval) date)) as breavement_time,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
res_employee_id=users.res_employee_id
and  date >='2018-04-16' and date <='2018-04-30' and release_no in
('sick_leave','casual_leave','privilege_leave','optional_holiday') ) as
leave,
'Not Submitted' state,
header.res_employee_id as header_emp_id,
'Not Submitted' as header_status

from res_users users,
res_partner partner,
tms_timesheet_status status,
tms_timesheet_header header

where 
header.res_employee_id=users.res_employee_id
and  status.id=header.status_id
and users.partner_id=partner.id
and status.name='Draft'
and header.timesheet_period_id=127
and header.res_employee_id in ('14145', '14147',
'ON-14148', '11331', '11332', '11333', 'ON-11334', '65432', '65416',
'54643', '23266', '4681', '56464', '64649', '89564', '98798', '1',
'44466', '87852', '65464', '65464', '44655', '8201', '65465', 'ON-78785',
'13233', 'ON-5544', 'ON-54654', '23131', '98765', '25134', '13218', '84645',
'4687', '6546', '4988', '89796', '79878', '7198', '15726', '2132', '5310',
'13056', '4446', '16825', '16740', '3912', '19601', '13200', '12981',
'ON-3332', '13166', 'ON-3144', 'ON-1251', 'ON-2799', 'ON-2338', '7286',
'ON-2381', 'ON-3102', 'ON-2938', '64782', '5407', '54641', '46379',
'G151151', '5007', '6011', '5050', '20869', '20204', '12410', '10488',
'14582', '13574', '12982', '7884', '7788', '13417', '7922', '16744',
'16746', '16756', '8292', '16745', '19989', '8297', '5020', '14184',
'17161', '20767', '20753', '20289', '19979', '19975', '20272', '4292',
'G9341010', '14791', '5121', 'ON-1767', 'ON-581', 'ON-700', 'ON-437',
'ON-562', 'ON-1726', 'OFF-1060', 'ON-147', 'OFF-612', 'OFF-635', 'OFF-857',
'ON-900280', 'ON-1934', 'ON-1922', 'ON-2258', 'OFF-2537', 'ON-2872',

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[Pavan Teja]

Thanks a lot!  I will have a look

On Tue, May 22, 2018, 11:53 PM Justin Pryzby  wrote:

> On Tue, May 22, 2018 at 03:51:44AM -0700, pavan95 wrote:
> > Please find the output of explain(analyze,buffers) for the whole query in
> > the below link.
>
> > Seq Scan on res_users users (cost=750.92..1,836.69 rows=249 width=15)
> (actual time=3.962..17.544 rows=67 loops=1)
>
> Not sure but would you try creating an index on:
> res_users.res_employee_id
>
> > Seq Scan on res_users user1 (cost=0.00..58.03 rows=1,303 width=15)
> (actual time=0.002..0.002 rows=1 loops=1)
>
> Also the planner's estimate for table:res_users is off by 1300x..so you
> should
> probably vacuum analyze it then recheck.  I don't think we know what
> version
> postgres you have, but last week's patch releases include a fix which may
> be
> relevant (reltuples including dead tuples).
>
> Also I don't know the definition of this table or its indices:
> tms_workflow_history
>
> ..but it looks like an additional or modified index or maybe clustering the
> table on existing index might help (active? is_final_approver?)
> Or maybe this should be 3 separate indices rather than composite index?
> Perhaps some of those could be BRIN indices, depending on postgres version
>
> Justin
>

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[Justin Pryzby]

On Tue, May 22, 2018 at 03:51:44AM -0700, pavan95 wrote:
> Please find the output of explain(analyze,buffers) for the whole query in
> the below link.

> Seq Scan on res_users users (cost=750.92..1,836.69 rows=249 width=15) (actual 
> time=3.962..17.544 rows=67 loops=1) 

Not sure but would you try creating an index on:
res_users.res_employee_id

> Seq Scan on res_users user1 (cost=0.00..58.03 rows=1,303 width=15) (actual 
> time=0.002..0.002 rows=1 loops=1)

Also the planner's estimate for table:res_users is off by 1300x..so you should
probably vacuum analyze it then recheck.  I don't think we know what version
postgres you have, but last week's patch releases include a fix which may be
relevant (reltuples including dead tuples).

Also I don't know the definition of this table or its indices:
tms_workflow_history

..but it looks like an additional or modified index or maybe clustering the
table on existing index might help (active? is_final_approver?)
Or maybe this should be 3 separate indices rather than composite index?
Perhaps some of those could be BRIN indices, depending on postgres version

Justin

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi Justin,

Please find the output of explain(analyze,buffers) for the whole query in
the below link.

Link:  https://explain.depesz.com/s/dNkb   

Thanks in Advance!


Regards,
Pavan



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi all, 
Thank you so much for your valuable responses.Tried every aspect which you
have said for my sub-query.  
I hoped a better decrease in cost for my main query. But yes it decreased
but not to a great extent.
What I felt is to provide the main query and the associated table
definitions in the query. Please help me to tune the following big query. 
select res.id id,
  row_number() OVER () as sno,
   res.header_id,
   res.emp_id,
   res.alias alias,
   res.name as name,
   res.billed_hrs billed_hrs,
   res.unbilled_hrs unbilled_hrs,
   res.paid_time_off paid_time_off,
   res.unpaid_leave unpaid_leave,
   res.breavement_time breavement_time,
   res.leave leave,
   res.state,
   count(*) OVER() AS full_count,
   res.header_emp_id,
   res.header_status
 from (
select 
history.id as id,
0 as header_id,
'0' as emp_id,
 row_number() OVER () as sno,
user1.alias_id as alias,
partner.name as name,
( select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
work_order_no != 'CORPORATE') billed_hrs,

(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'unbillable_time') as unbilled_hrs,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'paid_time_off') as paid_time_off,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'unpaid_leave') as unpaid_leave,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'bereavement_time') as breavement_time,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and date
>='2018-04-16' and date <='2018-04-30' and release_no in
('sick_leave','casual_leave','privilege_leave','optional_holiday') ) as
leave,
(case when tl_status.state = '' then 'Waiting for approval'
else tl_status.state end) as state,
header.res_employee_id as header_emp_id,
status.name as header_status 
from tms_workflow_history history, 
res_users users,
res_users user1,
res_partner partner,
tms_timesheet_status status,
tms_timesheet_header header
left join tms_workflow_history tl_status on
tl_status.timesheet_id=header.id
 and
tl_status.active=True
 and
tl_status.group_id=13

where 
 history.timesheet_id=header.id
and header.res_employee_id=user1.res_employee_id
and  status.id=header.status_id
and history.user_id=users.id
and user1.partner_id=partner.id
and header.timesheet_period_id = 127
 and (history.state = 'Approved' )
and history.current_activity='N'
and history.is_final_approver=True 
and history.active = True
   union 
select 
0 as id,
header.id as header_id,
'0' as emp_id,
 0 as sno,
users.alias_id as alias,
partner.name as name,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
work_order_no != 'CORPORATE' and
res_employee_id=users.res_employee_id and date in (select date::date from
generate_series((select start_date from tms_timesheet_period where
id=127),(select 

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi all, 
Thank you so much for your valuable responses.Tried every aspect which you
have said for my sub-query.  
I hoped a better decrease in cost for my main query. But yes it decreased
but not to a great extent.
What I felt is to provide the main query and the associated table
definitions in the query. Please help me to tune the following big query. 
select res.id id,
  row_number() OVER () as sno,
   res.header_id,
   res.emp_id,
   res.alias alias,
   res.name as name,
   res.billed_hrs billed_hrs,
   res.unbilled_hrs unbilled_hrs,
   res.paid_time_off paid_time_off,
   res.unpaid_leave unpaid_leave,
   res.breavement_time breavement_time,
   res.leave leave,
   res.state,
   count(*) OVER() AS full_count,
   res.header_emp_id,
   res.header_status
 from (
select 
history.id as id,
0 as header_id,
'0' as emp_id,
 row_number() OVER () as sno,
user1.alias_id as alias,
partner.name as name,
( select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
work_order_no != 'CORPORATE') billed_hrs,

(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'unbillable_time') as unbilled_hrs,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'paid_time_off') as paid_time_off,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'unpaid_leave') as unpaid_leave,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and
release_no = 'bereavement_time') as breavement_time,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
timesheet_header_id=header.id and date
>='2018-04-16' and date <='2018-04-30' and release_no in
('sick_leave','casual_leave','privilege_leave','optional_holiday') ) as
leave,
(case when tl_status.state = '' then 'Waiting for approval'
else tl_status.state end) as state,
header.res_employee_id as header_emp_id,
status.name as header_status 
from tms_workflow_history history, 
res_users users,
res_users user1,
res_partner partner,
tms_timesheet_status status,
tms_timesheet_header header
left join tms_workflow_history tl_status on
tl_status.timesheet_id=header.id
 and
tl_status.active=True
 and
tl_status.group_id=13

where 
 history.timesheet_id=header.id
and header.res_employee_id=user1.res_employee_id
and  status.id=header.status_id
and history.user_id=users.id
and user1.partner_id=partner.id
and header.timesheet_period_id = 127
 and (history.state = 'Approved' )
and history.current_activity='N'
and history.is_final_approver=True 
and history.active = True
   union 
select 
0 as id,
header.id as header_id,
'0' as emp_id,
 0 as sno,
users.alias_id as alias,
partner.name as name,
(select SUM( floor(effort_hours) + ( (effort_hours -
floor(effort_hours)) / 0.6 ))
from tms_timesheet_details where 
work_order_no != 'CORPORATE' and
res_employee_id=users.res_employee_id and date in (select date::date from
generate_series((select start_date from tms_timesheet_period where
id=127),(select 

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[mlunnon]

pavan95 wrote
> *Query*:
> 
> explain select ... from tms_timesheet_details, tms_wsr_header header  
> where wsr_header_id=header.id and work_order_no != 'CORPORATE';
> 
>  QUERY PLAN
> -
>  Aggregate  (cost=9868.91..9868.92 rows=1 width=8)
>->  Hash Join  (cost=608.27..5647.67 rows=70354 width=8)
>  Hash Cond: (tms_timesheet_details.wsr_header_id = header.id)
>  ->  Seq Scan on tms_timesheet_details  (cost=0.00..3431.14
> rows=72378 width=12)
>Filter: ((work_order_no)::text <> 'CORPORATE'::text)
>  ->  Hash  (cost=399.23..399.23 rows=16723 width=4)
>->  Seq Scan on tms_wsr_header header  (cost=0.00..399.23
> rows=16723 width=4)
> (7 rows)
> 
> 
> --
> Sent from:
> http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Why is the table tms_wsr_header in the from clause as it is not used in the
select columns? A simple "wsr_header_id is not null" would do the same as
this is a foreign key into the tms_wsr_header table. An index with on
tms_timesheet_details.id "where wsr_header_id is not null" might then speed
the query up if there were significant numbers of rows with a null
wsr_header_id.
Cheers
Matthew



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[David G. Johnston]

On Mon, May 21, 2018 at 7:43 AM, pavan95 
wrote:

> Hi David,
>
> Thank you so much for your valuable inputs.  Is there anything that I need
> to look from Indexes perspective or Join order ??
>
> Kindly let me know if  it can be tuned further.
>

What I've got to give here is what you've received.

David J.
​

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi David,

Thank you so much for your valuable inputs.  Is there anything that I need
to look from Indexes perspective or Join order ??

Kindly let me know if  it can be tuned further.

Thank you very much.  


Regards,
Pavan



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi abbas,

Thank you so much.  I've got this query from my development team asking to
improve its performance. 

Now I got pretty much clear idea of it. And it will be the final extent to
which we can tune the performance right?

If there is still a way give me some tips to enhance the query performance. 

But kudos for your "floor" function. After a long struggle with the indexes,
joins and the hints I came to know that there is also a way to tune the
query performance by rewriting the query.

Thanks in advance.

Regards,
Pavan



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[Abbas]

Sure thing. Base 60 or Sexagesimal is the numerical system used for 
measuring time (1 hour equals to 60 minutes and so on). But this case 
is even simpler, so without going into much detail about bases, you're 
mapping between two sets of numbers:


0 -> 0
.15 -> .25
.30 -> .50
.45 -> .75

From working with clocks, we know that 15 minutes is .25 hours, 30 
minutes is .5 hours and so on. So you only need to divide the 
fractional part ( effort_hours - floor(effort_hours) ) by .6 to get 
what you want.


For example, let's say effort_hours = 1.15; then floor(1.15) is 1; so:

floor(1.15) + ( (1.15 - floor(1.15)) / 0.6 ) = 1 + ( (1.15 - 1) / 0.6 ) 
= 1 + ( 0.15 / 0.60 ) = 1.25


Hope it helps. Feel free to ask a question if it's still unclear. :)


On Mon, May 21, 2018 at 6:09 PM, pavan95  
wrote:

Hi Abbas,

Thanks for your valuable suggestions. To my surprise I got the same 
output

as what I have executed before.

But unfortunately I'm unable to understand the logic of the code, in
specific what is base 60 number? The used data type for "effort_hours"
column is 'double precision'.

Kindly help me in understanding the logic. Thanks in advance.

Regards,
Pavan



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[David G. Johnston]

On Mon, May 21, 2018 at 6:39 AM, pavan95 
wrote:

> Hi Abbas,
>
> Thanks for your valuable suggestions. To my surprise I got the same output
> as what I have executed before.
>
> But unfortunately I'm unable to understand the logic of the code, in
> specific what is base 60 number? The used data type for "effort_hours"
> column is 'double precision'.
>
> Kindly help me in understanding the logic. Thanks in advance.


This is not converting a "base 60 number to base 10" - this is computing a
percentage, which is indeed what you want to do.

Since 0.60 is the maximum value of the fraction in this encoding scheme
dividing the actual value by 0.60 tells you what percentage (between 0 and
1) your value is of the maximum.  But you have to get rid of the hours
component first, and floor truncates the minutes leaving just the hours
which you can subtract out from the original leaving only the minutes.
​
David J.​

P.S. ​You could consider adding a new column to the table, along with a
trigger, and compute and store the derived value upon insert.
​

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi Abbas,

Thanks for your valuable suggestions. To my surprise I got the same output
as what I have executed before. 

But unfortunately I'm unable to understand the logic of the code, in
specific what is base 60 number? The used data type for "effort_hours"
column is 'double precision'. 

Kindly help me in understanding the logic. Thanks in advance.

Regards,
Pavan



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[Abbas]

Hi. Basically you want to convert a base 60 number to a decimal. So you 
don't need conditionals. See if this works for you:


SELECT floor(effort_hours) + ( (effort_hours - floor(effort_hours)) / 
0.6 )

from tms_timesheet_details detail , tms_wsr_header header  where
wsr_header_id=header.id and work_order_no != 'CORPORATE';

Regards,
Abbas

On Mon, May 21, 2018 at 3:43 PM, pavan95  
wrote:

Hi mlunon,

A great thanks for your timely response. And yes it worked when I 
rewritten

the query.

The query got enhanced with approximate of 1000 planner seeks. You 
can find

it from the explain plan below:

amp_test=# explain select
sum (
CASE MOD(cast(effort_hours as decimal),1)
WHEN 0.45 THEN cast(effort_hours as int)+0.75
WHEN 0.15 THEN cast(effort_hours as int)+0.25
WHEN 0.30 THEN cast(effort_hours as int)+0.5
WHEN 0 THEN cast(effort_hours as int)
END
)
from tms_timesheet_details detail , tms_wsr_header header  where
wsr_header_id=header.id and work_order_no != 'CORPORATE';
   QUERY PLAN

 Aggregate  (cost=8813.60..8813.61 rows=1 width=8)
   ->  Hash Join  (cost=608.27..5647.67 rows=70354 width=8)
 Hash Cond: (detail.wsr_header_id = header.id)
 ->  Seq Scan on tms_timesheet_details detail  
(cost=0.00..3431.14

rows=72378 width=12)
   Filter: ((work_order_no)::text <> 'CORPORATE'::text)
 ->  Hash  (cost=399.23..399.23 rows=16723 width=4)
   ->  Seq Scan on tms_wsr_header header  
(cost=0.00..399.23

rows=16723 width=4)
(7 rows)


But is this the optimum, can we reduce the cost more at least to 
around 5000
planner seeks. As it is only a subpart of the query which is called 
multiple

number of times in the main query.

And to send the main query along with tables description and explain 
plan it

will be a vast message so send you a sub-part.

Please help me to tune it more. Thanks in Advance.

Regards,
Pavan



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi mlunon,

A great thanks for your timely response. And yes it worked when I rewritten
the query.

The query got enhanced with approximate of 1000 planner seeks. You can find
it from the explain plan below:

amp_test=# explain select
sum (
CASE MOD(cast(effort_hours as decimal),1)
WHEN 0.45 THEN cast(effort_hours as int)+0.75
WHEN 0.15 THEN cast(effort_hours as int)+0.25
WHEN 0.30 THEN cast(effort_hours as int)+0.5
WHEN 0 THEN cast(effort_hours as int)
END
)
from tms_timesheet_details detail , tms_wsr_header header  where
wsr_header_id=header.id and work_order_no != 'CORPORATE';
   QUERY PLAN

 Aggregate  (cost=8813.60..8813.61 rows=1 width=8)
   ->  Hash Join  (cost=608.27..5647.67 rows=70354 width=8)
 Hash Cond: (detail.wsr_header_id = header.id)
 ->  Seq Scan on tms_timesheet_details detail  (cost=0.00..3431.14
rows=72378 width=12)
   Filter: ((work_order_no)::text <> 'CORPORATE'::text)
 ->  Hash  (cost=399.23..399.23 rows=16723 width=4)
   ->  Seq Scan on tms_wsr_header header  (cost=0.00..399.23
rows=16723 width=4)
(7 rows)


But is this the optimum, can we reduce the cost more at least to around 5000
planner seeks. As it is only a subpart of the query which is called multiple
number of times in the main query.

And to send the main query along with tables description and explain plan it
will be a vast message so send you a sub-part.

Please help me to tune it more. Thanks in Advance.

Regards,
Pavan



--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[mlunnon]

pavan95 wrote
> Hi all,
> 
> Hope my mail finds you in good time. I had a problem with a query which is
> hitting the production seriously.
> The below is the sub part of the query for which I cannot reduce the CPU
> cost. 
> 
> Please check and verify whether I'm doing wrong or whether that type index
> type suits it or not. 
> 
> Kindly help me resolve this issue.
> 
> *Query*:
> 
> explain select sum(CASE
>  WHEN MOD(cast(effort_hours as decimal),1) =
> 0.45 THEN
>  cast(effort_hours as int)+0.75
>  ELSE
>  CASE
>  WHEN MOD(cast(effort_hours as decimal),1)
> =
> 0.15 THEN
>  cast(effort_hours as int) + 0.25
> 
>   ELSE
>  CASE
>  WHEN MOD(cast(effort_hours as decimal),1)
> =
> 0.30 THEN
>  cast(effort_hours as int) + 0.5
> 
>   ELSE
>  CASE
>  WHEN MOD(cast(effort_hours as decimal),1)
> =
> 0 THEN
>  cast(effort_hours as int) 
>  end
>  END
>  END
>  END) from tms_timesheet_details,
> tms_wsr_header
> header  where wsr_header_id=header.id and work_order_no != 'CORPORATE';
> 
> 
> 
> --
> Sent from:
> http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

To start with you can try re-writing this so that it only does the mod cast
once. e.g:
sum ( 
CASE MOD(cast(effort_hours as decimal),1)
WHEN 0.45 THEN cast(effort_hours as int)+0.75
WHEN 0.15 THEN cast(effort_hours as int)+0.25
WHEN 0.30 THEN cast(effort_hours as int)+0.5
WHEN 0 THEN cast(effort_hours as int)
END
)




--
Sent from: 
http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html

Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!

[pavan95]

Hi all,

Hope my mail finds you in good time. I had a problem with a query which is
hitting the production seriously.
The below is the sub part of the query for which I cannot reduce the CPU
cost. 

Please check and verify whether I'm doing wrong or whether that type index
type suits it or not. 

Kindly help me resolve this issue.

*Query*:

explain select sum(CASE
 WHEN MOD(cast(effort_hours as decimal),1) =
0.45 THEN
 cast(effort_hours as int)+0.75
 ELSE
 CASE
 WHEN MOD(cast(effort_hours as decimal),1) =
0.15 THEN
 cast(effort_hours as int) + 0.25

  ELSE
 CASE
 WHEN MOD(cast(effort_hours as decimal),1) =
0.30 THEN
 cast(effort_hours as int) + 0.5

  ELSE
 CASE
 WHEN MOD(cast(effort_hours as decimal),1) =
0 THEN
 cast(effort_hours as int) 
 end
 END
 END
 END) from tms_timesheet_details, tms_wsr_header
header  where wsr_header_id=header.id and work_order_no != 'CORPORATE';

 QUERY PLAN
-
 Aggregate  (cost=9868.91..9868.92 rows=1 width=8)
   ->  Hash Join  (cost=608.27..5647.67 rows=70354 width=8)
 Hash Cond: (tms_timesheet_details.wsr_header_id = header.id)
 ->  Seq Scan on tms_timesheet_details  (cost=0.00..3431.14
rows=72378 width=12)
   Filter: ((work_order_no)::text <> 'CORPORATE'::text)
 ->  Hash  (cost=399.23..399.23 rows=16723 width=4)
   ->  Seq Scan on tms_wsr_header header  (cost=0.00..399.23
rows=16723 width=4)
(7 rows)


The count of number of rows in the tables used are:

1) tms_timesheet_details:

amp_test=# select count(*) from tms_timesheet_details;
 count

 110411
(1 row)

2) tms_wsr_header:

amp_test=# select count(*) from tms_wsr_header;
 count
---
 16723
(1 row)


The details of the tables and the columns used are as below:

1) tms_timesheet_details:

amp_test=# \d tms_timesheet_details
  Table
"public.tms_timesheet_details"
   Column|Type |
Modifiers
-+-+
 id  | integer | not null default
nextval('tms_timesheet_details_id_seq'::regclass)
 status  | character varying   |
 create_uid  | integer |
 effort_hours| double precision|
 work_order_no   | character varying   |
 res_employee_id | character varying   |
 wsr_header_id   | integer |
 remarks | character varying   |
 write_date  | timestamp without time zone |
 timesheet_header_id | integer |
 date| date|
 create_date | timestamp without time zone |
 write_uid   | integer |
 release_no  | character varying   |
 project_id  | character varying   |
 loc_name| character varying   |
 user_id | integer |
 ao_emp_id   | character varying   |
Indexes:
"tms_timesheet_details_pkey" PRIMARY KEY, btree (id)
"tms_timesheet_details_uniq_res_employee_id_efforts" UNIQUE, btree
(res_employee_id, work_order_no, release_no, date, project_id)
"timesheet_detail_inx" btree (wsr_header_id, timesheet_header_id)
"ts_detail_date_idx" btree (date)
"ts_detail_hdr_id_idx" btree (timesheet_header_id)
"ts_detail_release_no_idx" btree (release_no)
"work_order_no_idx" btree (work_order_no)
Foreign-key constraints:
"tms_timesheet_details_create_uid_fkey" FOREIGN KEY (create_uid)
REFERENCES res_users(id) ON DELETE SET NULL
"tms_timesheet_details_timesheet_header_id_fkey" FOREIGN KEY
(timesheet_header_id) REFERENCES tms_timesheet_header(id) ON DELETE SET NULL
"tms_timesheet_details_user_id_fkey" FOREIGN KEY (user_id) REFERENCES
res_users(id) ON DELETE SET NULL
"tms_timesheet_details_write_uid_fkey" FOREIGN KEY (write_uid)
REFERENCES res_users(id) ON DELETE SET NULL
"tms_timesheet_details_wsr_header_id_fkey" FOREIGN KEY (wsr_header_id)
REFERENCES tms_wsr_header(id) ON DELETE SET NULL


2) tms_wsr_header:

amp_test=# \d tms_wsr_header