On 2 January 2015 at 11:13, Amit Kapila <amit.kapil...@gmail.com> wrote:
> > On Fri, Jan 2, 2015 at 4:09 PM, Thom Brown <t...@linux.com> wrote: > > > > On 1 January 2015 at 10:34, Amit Kapila <amit.kapil...@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 > will most probably choose parallel plan only. > Ah, okay. Great. Thanks. Thom
