From: Martijn van Oosterhout <kleptog@svana.org>
To: Ron Peacetree <rjpeace@earthlink.net>
Cc: Jonah H. Harris <jonah.harris@gmail.com>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] A Better External Sort?
Date: Thu, 6 Oct 2005 18:57:30 +0200
Message-ID: <20051006165725.GF10127@svana.org> (raw)
In-Reply-To: <138872.1128556455518.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
References: <138872.1128556455518.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
On Wed, Oct 05, 2005 at 07:54:15PM -0400, Ron Peacetree wrote:
> I asked some questions about physical layout and format translation
> overhead being possibly suboptimal that seemed to be agreed to, but
> specifics as to where we are taking the hit don't seem to have been
> made explicit yet.
This hit is easy to see and terribly hard to do anything about at the
same time. Any single row in a table stores its values but the offsets
arn't constant. If a field is NULL, it is skipped. If a field is
variable length, you have to look at the length before you can jump
over to the next value.
If you have no NULLs and no variable length fields, then you can
optimise access. This is already done and it's hard to see how you
could improve it further. To cut costs, many places use
heap_deform_tuple and similar routines so that the costs are reduced,
but they're still there.
Upping the data transfer rate from disk is a worthy goal, just some
people beleive it is of lower priority than improving CPU usage.
> We were also told that evidently we are CPU bound far before one
> would naively expect to be based on the performance specifications
> of the components involved.
As someone pointed out, calls to the C library are not counted
seperately, making it harder to see if we're overcalling some of them.
Pinpointing the performance bottleneck is hard work.
> Now I've asked for the quickest path to detailed understanding of the
> pg IO subsystem. The goal being to get more up to speed on its
> coding details. Certainly not to annoy you or anyone else.
Well, the work is all in storage/smgr and storage/file. It's not
terribly complicated, it just sometimes takes a while to understand
*why* it is done this way.
Indeed, one of the things on my list is to remove all the lseeks in
favour of pread. Halving the number of kernel calls has got to be worth
something right? Portability is an issue ofcourse...
But it's been a productive thread, absolutly. Progress has been made...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
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: kleptog@svana.org, rjpeace@earthlink.net, jonah.harris@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] A Better External Sort?
In-Reply-To: <20051006165725.GF10127@svana.org>
* 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