Re: not exactly a bug report, but surprising behaviour

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: not exactly a bug report, but surprising behaviour
Date: 2003-02-05 07:34:32
Message-ID: 22981.1044430472@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I'm watching this query I'm working on now drive the cpu to 100% for 6+ hours
> with virtually no I/O. And I think it's the best I can do. All the times is
> being spent moving bits around from one place to another.

It would be interesting to see a gprof profile of that.

> It occurs to me that it's possible postgres is doing this already at a lower
> level of abstraction.

Yes, tuplesort.c has heard of pushing pointers around rather than
copying records. I wonder though whether data is being pushed out to
kernel disk buffers and then back in again --- do you have sort_mem
set large enough? Another likely theory is that the interface layers
needed to access datatype-specific comparison routines are chewing the
cycles. Need facts not speculation to know where the bottleneck is...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-02-05 07:44:26 Re: UPDATE slow
Previous Message John Smith 2003-02-05 06:41:34 Re: UPDATE slow