On Fri, Jan 2, 2015 at 4:09 PM, Thom Brown <thom@linux.com> wrote: > > On 1 January 2015 at 10:34, Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> > Running it again, I get the same issue. This is with parallel_seqscan_degree set to 8, and the crash occurs with 4 and 2 too. >> > >> > This doesn't happen if I set the pgbench scale to 50. I suspect this is a OOM issue. My laptop has 16GB RAM, the table is around 13GB at scale 100, and I don't have swap enabled. But I'm concerned it crashes the whole instance. >> > >> >> Isn't this a backend crash due to OOM? >> And after that server will restart automatically. > > > Yes, I'm fairly sure it is. I guess what I'm confused about is that 8 parallel sequential scans in separate sessions (1 per session) don't cause the server to crash, but in a single session (8 in 1 session), they do. >
It could be possible that master backend retains some memory
for longer period which causes it to hit OOM error, by the way
in your test does always master backend hits OOM or is it
random (either master or worker)
Just ran a few tests, and it appears to always be the master that hits OOM, or at least I don't seem to be able to get an example of the worker hitting it.
> > Will there be a GUC to influence parallel scan cost? Or does it take into account effective_io_concurrency in the costs? >
> And will the planner be able to decide whether or not it'll choose to use background workers or not? For example: >
Yes, we are planing to introduce cost model for parallel
communication (there is some discussion about the same
upthread), but it's still not there and that's why you
are seeing it to choose parallel plan when it shouldn't.
Currently in patch, if you set parallel_seqscan_degree, it