|From:||Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>|
|To:||Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>|
|Cc:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Avoid stuck of pbgench due to skipped transactions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Mon, 14 Jun 2021 16:06:10 +0900
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote:
> On Mon, 14 Jun 2021 08:47:40 +0200 (CEST)
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> > > I attached the fixed patch that uses return instead of break, and I confirmed
> > > that this made the progress reporting work property.
> > I'm hesitating to do such a strictural change for a degenerate case linked
> > to "insane" parameters, as pg is unlikely to reach 100 million tps, ever.
> > It seems to me enough that the command is not blocked in such cases.
> Sure. The change from "break" to "return" is just for making the progress
> reporting work in the loop, as you mentioned. However, my original intention
> is avoiding stuck in a corner-case where a unrealistic parameter was used, and
> I agree with you that this change is not so necessary for handling such a
> special situation.
I attached the v2 patch to clarify that I withdrew the v3 patch.
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
|Next Message||John Naylor||2021-06-16 16:24:05||Re: a path towards replacing GEQO with something better|
|Previous Message||Tomas Vondra||2021-06-16 16:23:28||PoC: Using Count-Min Sketch for join cardinality estimation|