Re: RES: Priority to a mission critical transaction

Поиск
Список
Период
Сортировка
Искать
От
Brian Hurt
Тема
Re: RES: Priority to a mission critical transaction
Дата
Msg-id
456D8A65.3080400@janestcapital.com
Ответ на
Список
Дерево обсуждения
Priority to a mission critical transaction "Carlos H. Reimer" <carlos.reimer@opendb.com.br>
Re: Priority to a mission critical transaction Brad Nicholson <bnichols@ca.afilias.info>
Re: Priority to a mission critical transaction "Jim C. Nasby" <jim@nasby.net>
RES: Priority to a mission critical transaction "Carlos H. Reimer" <carlos.reimer@opendb.com.br>
Re: RES: Priority to a mission critical transaction Andreas Kostyrka <andreas@kostyrka.org>
Re: RES: Priority to a mission critical transaction Josh Berkus <josh@agliodbs.com>
Re: RES: Priority to a mission critical transaction Mark Kirkwood <markir@paradise.net.nz>
Re: RES: Priority to a mission critical transaction Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: RES: Priority to a mission critical transaction Mark Kirkwood <markir@paradise.net.nz>
Re: RES: Priority to a mission critical transaction Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: RES: Priority to a mission critical transaction Tom Lane <tgl@sss.pgh.pa.us>
Re: RES: Priority to a mission critical transaction Bruce Momjian <bruce@momjian.us>
Re: RES: Priority to a mission critical transaction Josh Berkus <josh@agliodbs.com>
Re: RES: Priority to a mission critical transaction Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: RES: Priority to a mission critical transaction Brian Hurt <bhurt@janestcapital.com>
Re: RES: Priority to a mission critical transaction Mark Lewis <mark.lewis@mir3.com>
Re: RES: Priority to a mission critical transaction Brian Hurt <bhurt@janestcapital.com>
Re: RES: Priority to a mission critical transaction Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: RES: Priority to a mission critical transaction Brian Hurt <bhurt@janestcapital.com>
Re: RES: Priority to a mission critical transaction Ron Mayer <rm_pg@cheapcomplexdevices.com>
Postgres and really huge tables Brian Hurt <bhurt@janestcapital.com>
Re: Postgres and really huge tables Scott Marlowe <smarlowe@g2switchworks.com>
Re: [pgsql-advocacy] Postgres and really huge tables "Joshua D. Drake" <jd@commandprompt.com>
Re: [pgsql-advocacy] Postgres and really huge tables Chris Mair <chris@1006.org>
Re: [pgsql-advocacy] Postgres and really huge tables Josh Berkus <josh@agliodbs.com>
Re: [pgsql-advocacy] Postgres and really huge tables "Luke Lonergan" <llonergan@greenplum.com>
Re: Postgres and really huge tables Tom Lane <tgl@sss.pgh.pa.us>
Re: [pgsql-advocacy] Postgres and really huge tables Oleg Bartunov <oleg@sai.msu.su>
Re: Postgres and really huge tables "Merlin Moncure" <mmoncure@gmail.com>
Re: Postgres and really huge tables Gavin Sherry <swm@alcove.com.au>
Ron Mayer wrote:

>Before asking them to remove it, are we sure priority inversion
>is really a problem?
>
>I thought this paper: http://www.cs.cmu.edu/~bianca/icde04.pdf
>did a pretty good job at studying priority inversion on RDBMs's
>including PostgreSQL on various workloads (TCP-W and TCP-C) and
>found that the benefits of setting priorities vastly outweighed
>the penalties of priority inversion across all the databases and
>all the workloads they tested.
>
>  
>
I have the same question.  I've done some embedded real-time 
programming, so my innate reaction to priority inversions is that 
they're evil.  But, especially given priority inheritance, is there any 
situation where priority inversion provides *worse* performance than 
running everything at the same priority?  I can easily come up with 
situations where it devolves to that case- where all processes get 
promoted to the same high priority.  But I can't think of one where 
using priorities makes things worse, and I can think of plenty where it 
makes things better.

Brian

В списке pgsql-performance по дате отправления
От: Alessandro Baretta
Дата:
Сообщение: NAMEDATALEN and performance
От: Mark Lewis
Дата:
FAQ