Re: getting execution plans with multiple database connections - Mailing list pgsql-general

From Tom Lane
Subject Re: getting execution plans with multiple database connections
Date
Msg-id 19984.1060973175@sss.pgh.pa.us
Whole thread Raw
In response to getting execution plans with multiple database connections  (Jenny Zhang <jenny@osdl.org>)
Responses Re: [osdldbt-general] Re: getting execution plans with  (Jenny Zhang <jenny@osdl.org>)
List pgsql-general
Jenny Zhang <jenny@osdl.org> writes:
> It works for power test(single database connection).  In other words, I
> can get execution plans for all the 21 queries if there is only one
> stream connecting to the database.

> But for the throughput test(multiple database connections), some query
> execution plan files are blank.  It seems to be random, for example, for
> the run at:
> http://khack.osdl.org/stp/277495/results/plan/
> throughput_stream1_query14.txt, throughput_stream3_query4.txt,
> throughput_stream3_query5.txt, throughput_stream4_query4.txt,
> throughput_stream4_query18.txt are of size 0.  And if I do the run
> again, a different set of files are blank.

I wonder if you are not running out of kernel file table slots.  The
described behavior sounds rather like the explain-ing script is failing
to notice that it couldn't open its output file.  If you haven't bumped
up the kernel's file table size (NFILE or similar parameter) and/or
adjusted Postgres' max_files_per_process parameter downwards to hold
Postgres to a small number of open files per backend, it's quite easy
for Postgres to eat all your file table slots.  Postgres itself
generally will not complain (it has strategies for dealing with ENFILE
failures), but an awful lot of other stuff will fall right over when
it can't open files.

            regards, tom lane

pgsql-general by date:

Previous
From: "Andrew L. Gould"
Date:
Subject: Re: Arrays and "goodness" in RDBMSs (was Re: join of array)
Next
From: Tino Wildenhain
Date:
Subject: Re: join of array