Thread added to TODO for item:
* Allow sequential scans to take advantage of other concurrent sequential scans, also called "Synchronised Scanning"
---------------------------------------------------------------------------
Jeff Davis wrote:
> I have updated my Synchronized Scan patch and have had more time for
> testing.
>
> Go to http://j-davis.com/postgresql/syncscan-results10.html
> where you can download the patch, and see the benchmarks that I've run.
>
> The results are very promising. I did not see any significant slowdown
> for non-concurrent scans or for scans that fit into memory, although I
> do need more testing in this area.
>
> The benchmarks that I ran tested the concurrent performance, and the
> results were excellent.
>
> I also added two new simple features to the patch (they're just
> #define'd tunables in heapam.h):
> (1) If the table is smaller than
> effective_cache_size*SYNC_SCAN_THRESHOLD then the patch doesn't do
> anything different from current behavior.
> (2) The scans can start earlier than the hint implies by setting
> SYNC_SCAN_START_OFFSET between 0 and 1. This is helpful because it makes
> the scan start in a place where the cache trail is likely to be
> continuous between the starting point and the location of an existing scan.
>
> I'd like any feedback, particularly any results that show a slowdown
> from current behavior. I think I fixed Luke's problem (actually, it was
> a fluke that it was even working at all), but I haven't heard back. Some
> new feedback would be very helpful.
>
> Thanks.
>
> Regards,
> Jeff Davis
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
