On Mon, Nov 29, 2010 at 10:30 AM, Jonathan Corbet <cor...@lwn.net> wrote: > On Sat, 27 Nov 2010 14:27:12 -0500 > Tom Lane <t...@sss.pgh.pa.us> wrote: > >> And the bottom line is: if there's any performance benefit at all, >> it's on the order of 1%. The best result I got was about 3200 TPS >> with hugepages, and about 3160 without. The noise in these numbers >> is more than 1% though. >> >> This is discouraging; it certainly doesn't make me want to expend the >> effort to develop a production patch. However, perhaps someone else >> can try to show a greater benefit under some other test conditions. > > Just a quick note: I can't hazard a guess as to why you're not getting > better results than you are, but I *can* say that putting together a > production-quality patch may not be worth your effort regardless. There > is a nice "transparent hugepages" patch set out there which makes > hugepages "just happen" when it seems to make sense and the system can > support it. It eliminates the need for all administrative fiddling and > for any support at the application level.
Neat! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
