> > The advantage of sync_scan_offset is that, in some situations, a
> > second scan can actually finish faster than if it were the only
query
> > executing, because a previous scan has already caused some blocks to
> > be cached. However, 16 is a small number because that benefit would
> > only be once per scan, and sync scans are only helpful on large
tables.
Agreed.
> Alright, understood. That last part is actually something I
> now want to avoid because it's using the current
> cache-spoiling behaviour of seqscans to advantage. I'd like
> to remove that behaviour, but it sounds like we can have both
> - SeqScans that don't spoil cache
> - Synch scans by setting "sync_scan_offset" to zero.
>
> > > > I like the idea of reducing tuning parameters, but we should, at
a
> > > > minimum, still allow an on/off button for sync scans. My tests
> > > > revealed that the wrong combination of
> > > > OS/FS/IO-Scheduler/Controller could result in bad I/O behavior.
> > >
> > > Agreed
> > >
> >
> > Do you have an opinion about sync_scan_threshold versus a simple
> > sync_scan_enable?
>
> enable_sync_scan?
Seems the suggested guc's are very related. IIRC The agreed suggestion
was to use NBuffers (or a percentage thereof ?) to decide whether to
spoil the buffer cache for a seq scan. I seems this same metric should
be used to decide whether to sync a scan when sync scan is enabled. So
when the tablesize is below NBuffers (or a percentage thereof) you
neighter recycle buffers nor sync the seq scans.
Andreas
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
