On Mon, 2007-04-02 at 19:10 -0400, Bruce Momjian wrote:
Where is the final version of this patch? What patches are stuck in the
patch moderator queue?
We already discussed the dependency that exists with this patch and you
accepted that.
--
Simon Riggs
EnterpriseDB
Simon Riggs wrote:
On Mon, 2007-04-02 at 19:10 -0400, Bruce Momjian wrote:
Where is the final version of this patch? What patches are stuck in the
patch moderator queue?
We already discussed the dependency that exists with this patch and you
accepted that.
Oh, that was the patch. I
Where is the final version of this patch? What patches are stuck in the
patch moderator queue?
---
Simon Riggs wrote:
On Sat, 2007-03-10 at 07:59 +, Simon Riggs wrote:
On Fri, 2007-03-09 at 18:05 -0500, Tom Lane
On Fri, 2007-03-09 at 18:05 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 16:45 -0500, Tom Lane wrote:
We do that anyway; but certainly Simon's patch ought not be injecting
an additional one.
It should be possible to pass that down from the planner
Simon Riggs wrote:
On Sat, 2007-03-10 at 07:59 +, Simon Riggs wrote:
On Fri, 2007-03-09 at 18:05 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 16:45 -0500, Tom Lane wrote:
We do that anyway; but certainly Simon's patch ought not be injecting
an
On Sat, 2007-03-10 at 23:26 +1300, Mark Kirkwood wrote:
Simon Riggs wrote:
New patch enclosed, implementation as you've requested.
Not ready to apply yet, but good for testing.
A quick test using the setup for Buffer cache is not scan resistant
thread:
Firstly vanilla 8.3 from
Patch to implement buffer cache recycling for scans, as being discussed
on pgsql-hackers.
Applies cleanly to cvstip, passes make installcheck when used by default
for all SeqScans. Tested with scan_recycle_buffers = 1,4,8,16
Should be regarded as WIP. Presumably there are some failure conditions
Simon Riggs wrote:
Patch to implement buffer cache recycling for scans, as being discussed
on pgsql-hackers.
A few questions come to mind:
How does it behave with Jeff's synchronized seq scans patch?
I wonder if calling RelationGetNumberOfBlocks on every seq scan becomes
a performance issue
On Fri, 2007-03-09 at 20:08 +, Heikki Linnakangas wrote:
Simon Riggs wrote:
Patch to implement buffer cache recycling for scans, as being discussed
on pgsql-hackers.
A few questions come to mind:
Good questions. I don't expect this will go through easily, so we need
to examine these
Heikki Linnakangas [EMAIL PROTECTED] writes:
I wonder if calling RelationGetNumberOfBlocks on every seq scan becomes
a performance issue for tiny tables with for example just 1 page. It
performs an lseek, which isn't free.
We do that anyway; but certainly Simon's patch ought not be injecting
On Fri, 2007-03-09 at 16:45 -0500, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I wonder if calling RelationGetNumberOfBlocks on every seq scan becomes
a performance issue for tiny tables with for example just 1 page. It
performs an lseek, which isn't free.
We do that
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 16:45 -0500, Tom Lane wrote:
We do that anyway; but certainly Simon's patch ought not be injecting
an additional one.
It should be possible to pass that down from the planner to the
executor, in certain cases.
Huh? See
On Fri, 2007-03-09 at 20:37 +, Simon Riggs wrote:
I wonder if calling RelationGetNumberOfBlocks on every seq scan becomes
a performance issue for tiny tables with for example just 1 page. It
performs an lseek, which isn't free.
Jeff's patch does this also, for similar reasons.
As
On Fri, 2007-03-09 at 20:08 +, Heikki Linnakangas wrote:
Simon Riggs wrote:
Patch to implement buffer cache recycling for scans, as being discussed
on pgsql-hackers.
A few questions come to mind:
How does it behave with Jeff's synchronized seq scans patch?
I will test it and post
14 matches
Mail list logo
