> > The advantage of sync_scan_offset is that, in some situations, a 
> > second scan can actually finish faster than if it were the only
> > 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


> 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
> > > > 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.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to