Re: idea for concurrent seqscans

On Sat, 2005-02-26 at 10:47 -0500, Tom Lane wrote:
> "Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> > Assuming you're talkning about "You might wonder why we don't order all
> > the regression test queries explicitly to get rid of this issue once and
> > for all. The reason is that that would make the regression tests less
> > useful, not more, since they'd tend to exercise query plan types that
> > produce ordered results to the exclusion of those that don't.", good
> > point. I can think of 2 ways around this:
>
> > 1) Select into a temptable, then select out of it with an order by
>
> > 2) Run the output through sort before doing the diff
>
> > Is there any reason one of these wouldn't work?
>
> Like I said originally, we could certainly devise a solution if we
> needed to. I was just pointing out that this is a nontrivial
> consideration, and I don't want to buy into it if the patch proves
> to offer only marginal performance improvements.

Yes, the starting place is performance prototyping. Jeff has sensibly
started with that thought in his initial post.

I would suggest that we used a new GUC
enable_synch_scans = off, by default.
to control whether this new behaviour was utilised.

That way, all of the current tests would stand as-is. My feeling is that
in general, we should only add tests, not alter existing ones. It would
be straightforward, even if laborious, to add some additional tests that
prove that this type of system feature returns correct SQL results.
However, the key seems to be that the results of SQL runs without an
ORDER BY would be timing dependant, so would actually be a wholly new
type of test - we would need to run 1 on its own, then compare with 2
run together to check the same answer was still returned, possibly with
a post execution external sort.

Best Regards, Simon Riggs