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
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? |