Re: Warm-cache prefetching

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Kenneth Marshall <ktm(at)is(dot)rice(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Warm-cache prefetching
Date: 2005-12-09 16:18:45
Message-ID: 12988.1134145125@sss.pgh.pa.us
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:
> I can see that being useful for a single-user application that doesn't
> have locking or I/O bottlenecks, and doesn't have a multi-stage design
> like a database. Do we do enough of such processing that we will _see_
> an improvement, or will our code become more complex and it will be
> harder to make algorithmic optimizations to our code?

The main concern I've got about this is the probable negative effect on
code readability. There's a limit to the extent to which I'm willing to
uglify the code for processor-specific optimizations, and that limit is
not real far off. There are a lot of other design levels we can work at
to obtain speedups that won't depend on the assumption we are running
on this-year's Intel hardware.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2005-12-09 16:19:59 Re: Foreign key trigger timing bug?
Previous Message Martijn van Oosterhout 2005-12-09 16:17:33 Re: Upcoming PG re-releases