Re: Streaming read-ready sequential scan code
От | Thomas Munro |
---|---|
Тема | Re: Streaming read-ready sequential scan code |
Дата | |
Msg-id | CA+hUKGJFZ7ypOq=10tBwv6saWNU2gWKodjE9C2p1t=7cGv65ig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming read-ready sequential scan code (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: Streaming read-ready sequential scan code
|
Список | pgsql-hackers |
On Wed, Aug 28, 2024 at 9:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > 2024-08-28 08:41:59.304 UTC [338251] DEBUG: starting background worker process "parallel worker for PID 338262" > 2024-08-28 08:41:59.304 UTC [338251] DEBUG: starting background worker process "parallel worker for PID 338262" > 2024-08-28 08:41:59.305 UTC [338263] DEBUG: InitPostgres > 2024-08-28 08:41:59.305 UTC [338264] DEBUG: InitPostgres > 2024-08-28 08:41:59.309 UTC [338263] NOTICE: 2024-08-28 08:41:59.309364+00 pid 338263 > 2024-08-28 08:41:59.310 UTC [338264] NOTICE: 2024-08-28 08:41:59.310079+00 pid 338264 > It looks like the two parallel workers were started simultaneously, but > then the second one lagged behind... Yeah. That's quite interesting, and must destabilise that simple-minded demo. I'm curious to know exactly what contention is causing that (about 3/4 of a millisecond that I don't see and now I want to know what it's waiting for), but it's a very crude test lacking timer resolution in the earlier messages, and it's an unrelated topic and a distraction. Perhaps it explains why you saw two different behaviours in Q15 with the patch and I didn't, though. Really it shouldn't be so sensitive to such variations, it's obviously a terrible plan, and TPC-DS needs a planner hacker mega-brain applied to it; I'm going to try to nerd-snipe one...
В списке pgsql-hackers по дате отправления: