Re: making use of large TLB pages

From: Neil Conway <neilc(at)samurai(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: making use of large TLB pages
Date: 2002-09-29 15:21:22
Message-ID: 87znu0vn2l.fsf@mailbox.samurai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> OK, personally, I would like to see an actual speedup of PostgreSQL
> queries before I would apply such a OS-specific, version-specific
> patch.

Don't be silly. A performance improvement is a performance
improvement. According to your logic, using assembly-optimized locking
primitives shouldn't be done unless we've exhausted every possible
optimization in every other part of the system (a process which will
likely never be finished).

If the optimization was for some obscure UNIX variant and/or an
obscure processor, I would agree that it wouldn't be worth the
bother. But given that

(a) Linux on IA32 is likely our most popular platform [1]

(b) In theory, this will help performance where we need it
most, IMHO (high-end systems using large shared buffers)

I think it's at least worth implementing -- if it doesn't provide a
noticeable performance improvement, then we don't need to merge it.

Cheers,

Neil

[1] It's worth noting that the huge tlb patch currently works in IA64,
SPARC, and may well be ported to additional architectures in the
future.

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-09-29 15:30:23 Re: Do we want a CVS branch now?
Previous Message Tom Lane 2002-09-29 15:03:30 Re: pg_config : postgresql.conf adjustments?