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 pat
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 http:
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 w
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 van
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 add
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 ad
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 fro
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
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
"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 H
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
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 injec
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 t
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
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
15 matches
Mail list logo