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 sgend...@ideasculptor.com
Sent from my iPhone
On Nov 7, 2011, at 7:21 PM, Mohamed Hashim nmdhas...@gmail.com wrote:
Hi all,
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
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
On 10/11/11 09:39, Jay Levitt wrote:
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
Hello
2011/11/9 kzsolt kzsoltkzs...@freemail.hu:
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
Strange, John W john.w.stra...@jpmorgan.com 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
On Wed, Nov 9, 2011 at 8:16 PM, Scott Marlowe scott.marl...@gmail.comwrote:
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) -
PIDUSER PR NI VIRTRES
