Re: old synchronized scan patch - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: old synchronized scan patch
Date
Msg-id 1165434408.2048.18.camel@dogma.v10.wvs
Whole thread Raw
In response to Re: old synchronized scan patch  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: old synchronized scan patch  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
On Wed, 2006-12-06 at 19:04 +0000, Simon Riggs wrote:
> I envisaged that we would handle the problem by having a large SeqScan
> reuse its previous buffers so it would avoid polluting the cache. If we
> kept track of how many backends were in link-step together (a "Conga")
> we would be able to check that a block had not been used by anyone but
> the Conga members.
> 

Interesting idea.

> So we'd need rules about
> - when to allow a Conga to form (if file is very big we check, if not we
> don't, no real need for exact synchronisation in all cases)
> - how to join a Conga
> - how to leave a Conga if you fall behind
> 

How would one leave a Conga? What if it's in a user-defined function, or
if it's using the results for a nested loop join or something? So, we
can't wait for a backend to leave voluntarily, it would have to be a
plan where, when the backend goes back to get another block, it realizes
that the train has left the station, and goes at it alone (or makes it's
own Conga).

If you make the join/leave operations such that there is no resistance
at all (no timeout or anything), then it becomes the same as my non-
synchronized proposal, right?

> The cost of synchronisation (i.e. LWlocks) is much less than the cost of
> non-synchronisation (i.e. lots more I/O).
> 

If we can have a good way to synchronize it, that sounds good to me.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug in PostGreSQL 8.2
Next
From: "Simon Riggs"
Date:
Subject: Re: psql return codes