Re: Sync Scan update - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Sync Scan update
Date
Msg-id 87lkl3kbgo.fsf@enterprisedb.com
Whole thread Raw
In response to Re: Sync Scan update  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Sync Scan update
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:

> Like to see some tests with 2 parallel threads, since that is the most
> common case. I'd also like to see some tests with varying queries,
> rather than all use select count(*). My worry is that these tests all
> progress along their scans at exactly the same rate, so are likely to
> stay in touch. What happens when we have significantly more CPU work to
> do on one scan - does it fall behind??

If it's just CPU then I would expect the cache to help the followers keep up
pretty easily. What concerns me is queries that involve more I/O. For example
if the leader is doing a straight sequential scan and the follower is doing a
nested loop join driven by the sequential scan. Or worse, what happens if the
leader is doing a nested loop and the follower which is just doing a straight
sequential scan is being held back?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Sync Scan update
Next
From: Jeff Davis
Date:
Subject: Re: Sync Scan update