Benjamin Arai wrote: > My problem with [1] is that even for 10 users the percentage of time > spent in locks is very high. Really? In the paper referenced in the thread you quoted, figure 1H shows TCP-C with PostgreSQL and shows that time spent in locks with 10 users is extremely small (about 10% of time in locks with 5 warehouses and near 0% at 30 warehouses). This is in contrast with DB2 which shows about 80% time in locks with 5 warehouses and ten clients. Perhaps you were thinking DB2? With TCP-W, neither PostgreSQL nor DB2 shows any significant time spent in locks with 12 clients. > Can priorities scale? The PostgreSQL-priority-mechanisms paper referenced in this thread used TPC-C using 500MB - 3GB databases with 10 warehouses and from 1 to 300 Clients and TPC-W with 150MB and between 12 and 150 clients. So I'd say yes, it scales to meet most needs. > > Benjamin > > Ron Mayer wrote: >> Bruce Momjian wrote: >> >>> Hard to argue with that. >>> >> >> Is it a strong enough argument to add a TODO? >> >> >> I'm thinking some sort of TODO might be called for. >> >> Perhaps two TODOs? >> * Use the OS's priority features to prioritize >> backends (and document that it might work >> better with OS's that support priority inheritance). >> * Investigate if postgresql could develop an >> additional priority mechanism instead of using >> the OS's. >> >> >>> Ron Mayer wrote: >>> >>>> Magnus Hagander wrote: ... >>>> >>>>> quite likely to suffer from priority inversion >>>>> >>>> ... CMU paper... tested PostgreSQL (and DB2) on TPC-C and TPC-W >>>> ...found that...I/O scheduling through CPU priorities is a big win >>>> for postgresql. >>>> >>>> http://www.cs.cmu.edu/~bianca/icde04.pdf >>>> >> >> Setting priorities seems a rather common request, >> supposedly coming up every couple months [5]. >> >> The paper referenced [1] suggests that even with >> naive schedulers, use of CPU priorities is very >> effective for CPU and I/O intensive PostgreSQL >> workloads. >> >> If someone eventually finds a workload that does suffer >> worse performance due to priority inversion, >> (a) they could switch to an OS and scheduler >> that supports priority inheritance; >> (b) it'd be an interesting case for a paper >> rebutting the CMU one; and >> (c) they don't have to use priorities. >> >> If a user does find he wants priority inheritance it >> seems Linux[1], BSD[2], some flavors of Windows[3], >> and Solaris[4] all seem to be options; even though >> I've only seen PostgreSQL specifically tested for >> priority inversion problems with Linux (which did >> not find problems but found additional benefit of >> using priority inheritance). >> >> >> >> >> [1] Linux with Priority inheritance showing benefits for >> PostgreSQL >> http://www.cs.cmu.edu/~bianca/icde04.pdf >> [2] BSD priority inheritance work mentioned: >> http://www.freebsd.org/news/status/report-july-2004-dec-2004.html >> [3] Windows priority inheritance stuff: >> http://msdn2.microsoft.com/en-us/library/aa915356.aspx >> [4] Solaris priority inheritance stuff >> http://safari5.bvdep.com/0131482092/ch17lev1sec7 >> http://www.itworld.com/AppDev/1170/swol-1218-insidesolaris/ >> [5] Tom suggests that priorities are a often requested feature. >> http://svr5.postgresql.org/pgsql-performance/2006-05/msg00463.php >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 3: Have you checked our extensive FAQ? >> >> http://www.postgresql.org/docs/faq >> >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > message can get through to the mailing list cleanly >
