Re: Help me in reducing the CPU cost for the high cost query below, as it is hitting production seriously!!
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!!
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!!
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!!
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!!
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!!
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!!
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!!
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!!
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 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
