On Tue, Sep 28, 2021 at 12:19 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Mon, Sep 27, 2021 at 10:52 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> >
> > And most of the time, that's probably a good bet. But, if you do
> > somehow hit the losing case repeatedly, then you could see a
> > significant regression. And that might explain Tomas's results.
> > Perhaps for some reason they just happen to hit that case over and
> > over again. If that's true, it would be useful to know why it happens
> > in that case and not others, because then maybe we could avoid the
> > problem somehow. However, I'm not sure how to figure that out, and I'm
> > not even entirely sure it's important to figure it out.
> >
>
> Yeah, if it is losing in some cases then it is definitely good to know
> the reason, I was just looking into the performance numbers shared by
> Tomas in query-results, I can see the worst case is
> with 10000000 rows, 10 columns and 4 threads and queue size 64k.
> Basically, if we see the execution time with head is ~804ms whereas
> with patch it is ~1277 ms. But then I just tried to notice the
> pattern with different queue size so number are like below,
>
> 16k 64k 256k 1024k
> Head 1232.779 804.24 1134.723 901.257
> Patch 1371.493 1277.705 862.598 783.481
>
> So what I have noticed is that in most of the cases on head as well as
> with the patch, increasing the queue size make it faster, but with
> head suddenly for this particular combination of rows, column and
> thread the execution time is very low for 64k queue size and then
> again the execution time increased with 256k queue size and then
> follow the pattern. So this particular dip in the execution time on
> the head looks a bit suspicious to me.
>
I concur with your observation. Isn't it possible to repeat the same
test in the same environment to verify these results?
--
With Regards,
Amit Kapila.
