sql - Best query for getting success/failure ratio from warehouse fact table -

i'm trying fine tune query , feedback. have job_fact warehouse table unit of measure job's final event (final_event_type). i'm trying run query on fact give me success/failure ratio. here's have far:

select   case when jf.final_event_type in (4,6,8,9) count(final_event_type) end num_failures,   case when jf.final_event_type in (5,7,10) count(final_event_type) end num_successes job_fact jf group jf.final_event_type; 

this query gives me raw succes , failure values in two-row result:

+----------------------+-----------------------+ | num_failures         | num_successes         | +----------------------+-----------------------+ | [null]               | 6                     | | 14                   | [null]                | +----------------------+-----------------------+ 

does know if there's way a) results on 1 line, , b) able calculate ratio between 2 (e.g. failure percentage). i'm assuming tell me i'm better off writing procedure this, i'd avoid if possible. know there's elegant way this, sql-foo lacking today guess.

i'm running postgresql 9.0.1. assistance may offer.

update

based off of chosen answer (from @ronnis), here final query, in case wondering:

select   sum(case when final_event_type in(4,6,8,9) 1 else 0 end) failures,   sum(case when final_event_type in(5,7,10)  1 else 0 end) successes, count(final_event_type) total_events,   sum(case when final_event_type in(4,6,8,9) 1 else 0 end) / count(final_event_type)::decimal failure_percentage,   sum(case when final_event_type in(5,7,10) 1 else 0 end) / count(final_event_type)::decimal success_percentage job_fact; 

if where final_event_type in(4,5,6,7,8,9,10) hit of table, think following pretty performant:

select sum(case when final_event_type in(4,6,8,9) 1 else 0 end) failures       ,sum(case when final_event_type in(5,7,10)  1 else 0 end) successes  job_fact; 

edit
don't know how postgresq executes above query. in oracle, there access path called index fast full scan, treats index table. no traversal (slow), full scan (efficient). benefit index on {final_event_type} smaller scan whole table. (i'm not mentioning bitmap indexes, because faster still).