Kevin Grittner wrote:
Jay Levitt 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 faster than 1.3 ms?
Yep
Merlin Moncure 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).
Well, that doesn't
On Wed, Nov 9, 2011 at 9:15 AM, Kevin Grittner
wrote:
> Jay Levitt 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
>> sele
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 partiti
Jay Levitt 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 (
>select u.id
>
On Wed, Nov 9, 2011 at 2:25 AM, Venkat Balaji 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 1.9g S
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 "wri
