Re: getting execution plans with multiple database connections

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jenny Zhang <jenny(at)osdl(dot)org>
Cc: pgsql-general(at)postgresql(dot)org, osdldbt-general(at)lists(dot)sourceforge(dot)net
Subject: Re: getting execution plans with multiple database connections
Date: 2003-08-15 18:46:15
Message-ID: 19984.1060973175@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jenny Zhang <jenny(at)osdl(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-08-15 18:49:41 Re: [GENERAL] 7.4Beta
Previous Message Andrew L. Gould 2003-08-15 18:37:50 Re: Arrays and "goodness" in RDBMSs (was Re: join of array)