[PERFORM] performance issue with a specific query
Hi!I hope I'm sending my question to the right list, please don't flame if it's the wrong one.I have noticed that while a query runs in about 1.5seconds on a 8.xx version postgresql server on our 7.4.13 it takes around 15-20 minutes. Since we are using RHEL4 on our server we are stuck with
7.4.13. The enormous time difference between the different builds drives me crazy. Can you please help me identifying the bottleneck or suggest anything to improve the dismal performance.The query is the following:
Select car_license_plate.license_plate, substr(date_trunc('day', car_km_fuel.transaction_time), 1, 10), substr(date_trunc('second', car_km_fuel.transaction_time), 12, 8), vehicle_make.make, vehicle_type.model,
engine_size, vehicle_fuel_type.fuel_type, v_org_person_displayname.displayname_lastfirst, car_km_fuel.ammount, car_km_fuel.unit_price, car_km_fuel.total_ammount, currency.currency AS,
car_km_fuel.km AS, vehicle_specific.fuel_capacity, CASE WHEN (car_km_fuel.ammount vehicle_specific.fuel_capacity) THEN CAST(ROUND(CAST(car_km_fuel.ammount - vehicle_specific.fuel_capacity AS NUMERIC), 2) AS varchar) ELSE '---' END AS over,
car_km_fuel.notes,CASE WHEN (prev_car_km_fuel.km IS NOT NULL AND car_km_fuel.km IS NOT NULL AND (car_km_fuel.km - prev_car_km_fuel.km 0)) THEN CAST(Round(CAST(((car_km_fuel.ammount / (car_km_fuel.km - prev_car_km_fuel.km)) * 100) AS Numeric), 2) AS VARCHAR)
WHEN (prev_car_km_fuel.km IS NULL) THEN '' WHEN (car_km_fuel.km IS NULL) THEN 'error' END AS average, vehicle_specific.consumption_town, org_person.email_addressFROM
car_km_fuelLEFT JOIN car ON car.id = car_km_fuel.car_idLEFT JOIN car_license_plate ON car_license_plate.car_id = car.id AND (car_license_plate.license_plate_end_date date_trunc('day', car_km_fuel.transaction_time) OR car_license_plate.license_plate_end_date IS NULL)
LEFT JOIN vehicle_specific ON vehicle_specific.id = car.vehicle_specific_idLEFT JOIN vehicle_variant ON vehicle_variant.id = vehicle_specific.vehicle_variant_idLEFT JOIN vehicle_type ON vehicle_type.id = vehicle_variant.vehicle_type_id
LEFT JOIN vehicle_make ON vehicle_make.id = vehicle_type.vehicle_make_idLEFT JOIN vehicle_fuel_type ON vehicle_fuel_type.id = vehicle_specific.fuel_type_idLEFT JOIN car_driver ON car_driver.car_id =
car.id AND car_driver.allocation_date = date_trunc('day', car_km_fuel.transaction_time) AND (car_driver.end_date = date_trunc('day', car_km_fuel.transaction_time) OR car_driver.end_date IS NULL)
LEFT JOIN v_org_person_displayname ON v_org_person_displayname.id = car_driver.car_driver_idLEFT JOIN org_person ON org_person.id = v_org_person_displayname.idLEFT JOIN currency ON
currency.id = car_km_fuel.currency_idLEFT JOIN car_km_fuel AS prev_car_km_fuel ON prev_car_km_fuel.transaction_time = (SELECT MAX(transaction_time) FROM car_km_fuel as car_km_fuel2 WHERE car_km_fuel2.car_id =
car.id AND car_km_fuel2.transaction_time car_km_fuel.transaction_time)LEFT JOIN org_company ON org_company.id = org_person.company_idWHERE (lower(org_company.name) LIKE lower(:param3) || '%') AND
(car_km_fuel.transaction_time = :param1 OR :param1 IS NULL) AND (car_km_fuel.transaction_time = :param2 OR :param2 IS NULL) ORDER BY 1, 2, 3;The output of explain if the following under
7.4.13:QUERY PLAN
-
Sort (cost=66.66..66.66 rows=1 width=917)Sort Key: car_license_plate.license_plate, substr((date_trunc('day'::text, car_km_fuel.transaction_time))::text, 1, 10), substr((date_trunc('second'::text, car_km_fuel.transaction_time))::text, 12, 8)
- Nested Loop (cost=44.93..66.65 rows=1 width=917) - Nested Loop Left Join (cost=44.93..62.23 rows=1 width=921)Join Filter: (inner.transaction_time = (subplan))
- Nested Loop Left Join (cost=44.93..62.21 rows=1 width=917) Join Filter: (inner.id = outer.currency_id) - Nested Loop (cost=
44.93..60.92 rows=1 width=828) - Hash Join (cost=44.93..58.32 rows=1 width=805) Hash Cond: (outer.id = inner.car_driver_id)
- Subquery Scan v_org_person_displayname (cost=16.42..28.82 rows=196 width=520) - Merge Right Join (cost=16.42..26.86 rows=196 width=51)
Merge Cond: (outer.id = inner.company_id)
Re: [PERFORM] performance issue with a specific query
On Thu, 2006-07-27 at 09:23, Eliott wrote:
Hi!
I hope I'm sending my question to the right list, please don't flame
if it's the wrong one.
I have noticed that while a query runs in about 1.5seconds on a 8.xx
version postgresql server on our 7.4.13 it takes around 15-20 minutes.
Since we are using RHEL4 on our server we are stuck with 7.4.13. The
enormous time difference between the different builds drives me crazy.
Can you please help me identifying the bottleneck or suggest anything
to improve the dismal performance.
You are absolutely on the right list. A couple of points.
1: Which 8.xx? 8.0.x or 8.1.x? 8.1.x is literally light years ahead
of 7.4 in terms of performance. 8.0 is somewhere between them. The
performance difference you're seeing is pretty common.
2: Looking at your query, there are places where you're joining on
things like date_trunc(...). In 7.4 the database will not, and cannot
use a normal index on the date field for those kinds of things. It can,
however, use a funtional index on some of them. Try creating an index
on date_trunc('day',yourfieldhere) and see if that helps.
3: You are NOT Stuck on 7.4.13. I have a RHEL server that will be
running 8.1.4 or so pretty soon as a dataware house. It may get updated
to RHEL4, may not. You can either compile from the .tar.[gz|bz2] files
or download the PGDG rpms for your distro.
4: You are fighting an uphill battle. There were a LOT of improvements
made all over in the march from 7.4 to 8.1. Not all of them were simple
planner tweaks and shortcuts, but honest to goodness changes to the way
things happen. No amount of tuning can make 7.4 run as fast as 8.1.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] performance issue with a specific query
On 7/27/06, Eliott [EMAIL PROTECTED] wrote: Hi! I hope I'm sending my question to the right list, please don't flame if it's the wrong one. I have noticed that while a query runs in about 1.5seconds on a 8.xx version postgresql server on our 7.4.13 it takes around 15-20 minutes. Since we are using RHEL4 on our server we are stuck with 7.4.13. The enormous time difference between the different builds drives me crazy. Can you please help me identifying the bottleneck or suggest anything to improve the dismal performance. The query is the following: try turning off genetic query optimization. regarding the rhel4 issue...does rhel not come with a c compiler? :) merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] performance issue with a specific query
try turning off genetic query optimization. regarding the rhel4 issue...does rhel not come with a c compiler? :) Enterprises are not going to compile. They are going to accept the latest support by vendor release. Redhat has a tendency to be incredibly stupid about this particular area of their packaging. Joshua D. Drake merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] performance issue with a specific query
Joshua D. Drake wrote: try turning off genetic query optimization. regarding the rhel4 issue...does rhel not come with a c compiler? :) Enterprises are not going to compile. They are going to accept the latest support by vendor release. Redhat has a tendency to be incredibly stupid about this particular area of their packaging. Stupid how? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] performance issue with a specific query
Alvaro Herrera [EMAIL PROTECTED] writes: Joshua D. Drake wrote: Enterprises are not going to compile. They are going to accept the latest support by vendor release. Redhat has a tendency to be incredibly stupid about this particular area of their packaging. Stupid how? Red Hat feels (apparently accurately, judging by their subscription revenue ;-)) that what RHEL customers want is a platform that's stable over multi-year application lifespans. So major incompatible changes in the system software are not looked on with favor. That's why RHEL4 is still shipping PG 7.4.*. You can call it a stupid policy if you like, but it's hard to argue with success. However, there will be an RH-supported release of PG 8.1.* as an optional add-on for RHEL4. Real Soon Now, I hope --- the release date has been pushed back a couple times already. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
