pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Steinar H. Gunderson <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: New to PostgreSQL, performance considerations
Date: Mon, 11 Dec 2006 12:25:47 +0100
Message-ID: <20061211112547.GA24571@uio.no> (raw)
In-Reply-To: <8a0c7af10612110305u305124b2v3d63491b5f57a86b@mail.gmail.com>
References: <8a0c7af10612101141n2c7727c3r2f92345753960808@mail.gmail.com>
	<430d92a20612101336r3de8862coe618277fccb4006a@mail.gmail.com>
	<8a0c7af10612101702i49b5a533v4a2300d90d9dae6b@mail.gmail.com>
	<20061211021847.GE16692@mathom.us>
	<8a0c7af10612110305u305124b2v3d63491b5f57a86b@mail.gmail.com>

On Mon, Dec 11, 2006 at 09:05:56AM -0200, Daniel van Ham Colchete wrote:
> But, trust me on this one. It's worth it.

You know what? I don't.

> Think of this: PostgreSQL and GNU LibC use a lot of complex algorithms:
> btree, hashes, checksums, strings functions, etc... And you have a lot of
> ways to compile it into binary code. Now you have Pentium4's vectorization
> that allow you to run plenty of instructions in paralell, but AMD doesn't
> have this. Intel also have SSE2 that makes double-precision floatpoint
> operations a lot faster, AMD also doesn't have this (at least on 32bits). 

Athlon 64 has SSE2, also in 32-bit-mode.

Of course, it doesn't really matter, since at the instant you hit the disk
even once, it's going to take a million cycles and any advantage you got from
saving single cycles is irrelevant.

> Imagine that you are GCC and that you have two options in front of
> you: you can use FSQRT or FDIV plus 20 ADD/SUB.

Could you please describe a reasonable case where GCC would have such an
option? I cannot imagine any.

> An example that I know of: it's impossible to run my software at a
> high demanding customer without compiling it to the it's processor (I
> make 5 compilations on every release).

What's "your software"? How can you make such assertions without backing them
up? How can you know that the same holds for PostgreSQL?

As Mike said, point to the benchmarks showing this "essential" difference
between -O2 and -O2 -mcpu=pentium4 (or whatever). The only single worthwhile
difference I can think of, is that glibc can use the SYSENTER function if it
knows you have a 686 or higher (which includes AMD), and with recent kernels,
I'm not even sure if that is needed anymore.

/* Steinar */
-- 
Homepage: http://www.sesse.net/



view thread (124+ messages)  latest in thread

Message-ID: <20061211112547.GA24571@uio.no>
Permalink:  ../20061211112547.GA24571@uio.no/
Also on:    postgresql.org/message-id/20061211112547.GA24571@uio.no

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: sgunderson@bigfoot.com
  Subject: Re: New to PostgreSQL, performance considerations
  In-Reply-To: <20061211112547.GA24571@uio.no>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox