Hello Everyone,
I could see the following in the production server (result of the top M
command) -
PIDUSER PR NI VIRTRES SHR S %CPU %MEM TIME+
COMMAND
25265 postgres 15 0 3329m 2.5g 1.9g S 0.0 4.0
542:47.83 postgres: writer process
The
On Wed, Nov 9, 2011 at 2:25 AM, Venkat Balaji venkat.bal...@verse.in wrote:
Hello Everyone,
I could see the following in the production server (result of the top M
command) -
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
25265 postgres 15 0 3329m 2.5g
Jay Levitt jay.lev...@gmail.com wrote:
I don't get why the GROUP BY in this subquery forces it to scan
the entire users table (seq scan here, index scan on a larger
table) when there's only one row in users that can match:
explain analyze
select questions.id
from questions
join (
On 11/07/2011 05:18 PM, Richard Yen wrote:
My biggest question is: we know from the docs that there should be no
more than (2 + checkpoint_completion_target) * checkpoint_segments + 1
files. For us, that would mean no more than 48 files, which equates
to 384MB--far lower than the 9.7GB
On Wed, Nov 9, 2011 at 9:15 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Jay Levitt jay.lev...@gmail.com wrote:
I don't get why the GROUP BY in this subquery forces it to scan
the entire users table (seq scan here, index scan on a larger
table) when there's only one row in users that
Merlin Moncure mmonc...@gmail.com wrote:
Well, this may not fit the OP's 'real' query
Right, if I recall correctly, the OP said it was simplified down as
far as it could be and still have the issue show.
but the inner subquery is probably better written as a semi-join
(WHERE EXISTS).
Kevin Grittner wrote:
Jay Levittjay.lev...@gmail.com wrote:
I don't get why the GROUP BY in this subquery forces it to scan
the entire users table (seq scan here, index scan on a larger
table) when there's only one row in users that can match:
Are you sure there's a plan significantly
