On Sat, 2008-05-31 at 22:01 -0400, Tom Lane wrote:
> I thought the end conclusion of that thread was to not do anything,
> on the grounds that
> (1) having new scans sometimes fail to join an existing syncscan
> herd would be a bad thing because of the resulting performance
> uncertainty;
> (2) par
Jeff Davis <[EMAIL PROTECTED]> writes:
> I was looking into supporting synchronized scans for VACUUM, and I
> noticed that we currently don't remove the reported scan location as
> this post suggests:
> http://archives.postgresql.org/pgsql-patches/2007-06/msg00047.php
I thought the end conclusion
I was looking into supporting synchronized scans for VACUUM, and I
noticed that we currently don't remove the reported scan location as
this post suggests:
http://archives.postgresql.org/pgsql-patches/2007-06/msg00047.php
There was some debate about whether it should be done, but I thought
that t
Jeff Davis wrote:
On Thu, 2007-05-31 at 09:08 +0100, Heikki Linnakangas wrote:
* moved the sync scan stuff to a new file access/heapam/syncscan.c.
heapam.c is long enough already, and in theory the same mechanism could
be used for large bitmap heap scans in the future.
Good idea, I hadn't tho
On Thu, 2007-05-31 at 09:08 +0100, Heikki Linnakangas wrote:
> Here's a work-in-progress update of this patch.
>
> I haven't done any major changes, but a lot of little refactoring and
> commenting, including:
>
> * moved the sync scan stuff to a new file access/heapam/syncscan.c.
> heapam.c is
Here's a work-in-progress update of this patch.
I haven't done any major changes, but a lot of little refactoring and
commenting, including:
* moved the sync scan stuff to a new file access/heapam/syncscan.c.
heapam.c is long enough already, and in theory the same mechanism could
be used for
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Je
On Mon, 2007-05-21 at 16:03 +0200, Peter Eisentraut wrote:
> Am Montag, 21. Mai 2007 00:01 schrieb Jeff Davis:
> > Here is the latest version of my patch that's revised according to my
> > discussions with Heikki and Simon:
>
> This patch was apparently done against 8.2.4, but it doesn't apply to
Am Montag, 21. Mai 2007 00:01 schrieb Jeff Davis:
> Here is the latest version of my patch that's revised according to my
> discussions with Heikki and Simon:
This patch was apparently done against 8.2.4, but it doesn't apply to CVS
head.
--
Peter Eisentraut
http://developer.postgresql.org/~pet
Here is the latest version of my patch that's revised according to my
discussions with Heikki and Simon:
Changes:
* uses LWLocks when accessing shared memory
* removes the "sync_seqscan_offset" feature
* uses the relfilenode as a key rather than relation OID
* fixes regression test failure
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Je
On Thu, 2007-03-22 at 16:43 -0400, Bruce Momjian wrote:
> Will use '16' rather than '100'.
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers revie
Will use '16' rather than '100'.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
--
On Thu, 2007-03-15 at 08:27 +, Simon Riggs wrote:
> On Wed, 2007-03-14 at 01:42 -0700, Jeff Davis wrote:
> > SYNC_SCAN_REPORT_INTERVAL 100
>
> Jeff,
>
> This will stop SeqScans from working with buffer recycling, unless we
> put the recycle limit to more than 100. That was why I requested you
On Wed, 2007-03-14 at 01:42 -0700, Jeff Davis wrote:
> SYNC_SCAN_REPORT_INTERVAL 100
Jeff,
This will stop SeqScans from working with buffer recycling, unless we
put the recycle limit to more than 100. That was why I requested you set
this to 16, so we can use a recycle buffer of 32.
--
Simon
This is my latest revision of the Sync Scan patch, and it implements the
observability as discussed with Simon.
Changes:
* ss_report_loc() called once per hundred pages rather than once per
page
* DEBUG messages are a little cleaner and easier to parse, for the sake
of analysis after the fact.
16 matches
Mail list logo
