On Fri, Mar 24, 2006 at 01:21:23PM -0500, Chris Browne wrote:
>A naive read on this is that you might start with one backend process,
>which then spawns 16 more. Each of those backends is scanning through
>one of those 16 files; they then throw relevant tuples into shared
>memory to be aggregated/joined by the central one.
Of course, table scanning is going to be IO limited in most cases, and
having every query spawn 16 independent IO threads is likely to slow
things down in more cases than it speeds them up. It could work if you
have a bunch of storage devices, but at that point it's probably easier
and more direct to implement a clustered approach.
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2006-03-24 19:23:49|
|Subject: Re: Performance problems with multiple layers of functions |
|Previous:||From: Svenne Krap||Date: 2006-03-24 19:16:29|
|Subject: Re: Performance problems with multiple layers of functions|