On Wed, Nov 9, 2011 at 8:16 PM, Scott Marlowe wrote:
> 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) -
> > PIDUSER PR NI VIRTRES SHR S %CPU %MEM TIME
"Strange, John W" writes:
> I have a question on how the analyzer works in this type of scenario.
> We calculate some results and COPY INTO some partitioned tables, which we use
> some selects to aggregate the data back out into reports. Everyone once in a
> while the aggregation step picks a b
Hello
2011/11/9 kzsolt :
> I try to found out more information. Looks like the COUNT(*) is not the
> strongest part of pgr therfore I do a worakround. After this I have the
> folwing result:
>
> Below the 1Mrec the row insert time is ~23msec. Above the 7Mrec the insert
> time is ~180msec.
>
* use
On 10/11/11 09:39, Jay Levitt wrote:
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 s
I try to found out more information. Looks like the COUNT(*) is not the
strongest part of pgr therfore I do a worakround. After this I have the
folwing result:
Below the 1Mrec the row insert time is ~23msec. Above the 7Mrec the insert
time is ~180msec.
I belive I use the fastest index type (def
I have a question on how the analyzer works in this type of scenario.
We calculate some results and COPY INTO some partitioned tables, which we use
some selects to aggregate the data back out into reports. Everyone once in a
while the aggregation step picks a bad plan due to stats on the tables
how about your harddisks??
you could get a little help from a RAID10 SAS 15k disks. if you don't even
have RAID, it would help a lot!
Lucas.
2011/11/8 Sam Gendler
>
>
> Sent from my iPhone
>
> On Nov 7, 2011, at 7:21 PM, Mohamed Hashim wrote:
>
> Hi all,
>
> Thanks for all your responses.
>
>
