Hi Scott,
Thanks for you suggestion. I have follow your suggestion by disable
nestloop and have a substantial improvement. Takes 51s now. I have
attached the new query plan in another file.
What I want to ask is, is there any other way to hint the planner to
choose to use merge join rather than
On Mon, Aug 10, 2009 at 12:22 AM, Ip Wing Kin Johnwkipj...@gmail.com wrote:
Hi Scott,
Thanks for you suggestion. I have follow your suggestion by disable
nestloop and have a substantial improvement. Takes 51s now. I have
attached the new query plan in another file.
What I want to ask is, is
On Mon, Aug 10, 2009 at 2:22 AM, Ip Wing Kin Johnwkipj...@gmail.com wrote:
Hi Scott,
Thanks for you suggestion. I have follow your suggestion by disable
nestloop and have a substantial improvement. Takes 51s now. I have
attached the new query plan in another file.
What I want to ask is, is
On Wed, Aug 5, 2009 at 11:21 PM, wkipj...@gmail.com wrote:
Sorry post again.
Nope, still mangled. Can you attach it?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Hi scott
I attached the query plan with this email. The top one is the first
run after I restarted my machine. And the bottom one is the second
run.
I am using PostgreSQL 8.3 on Solaris 10.
cheers
On Thu, Aug 6, 2009 at 4:15 PM, Scott Marlowescott.marl...@gmail.com wrote:
On Wed, Aug 5, 2009
OK, two things. First the row estimate starts going way off around
the time it gets to the hash aggregate / nested loop which seems to be
making the planner use a bad plan for this many rows. You can try
issuing
set enable_nestloop = off;
before running the query and see if that makes it any
On Thu, Aug 06, 2009 at 12:50:51PM +1000, Ip Wing Kin John wrote:
(running DTrace tool kit iofile.d script to show I/O wait time by
filename and process)
Is the dtrace toolkit a viable product for a linux environment or
is it strickly Sun/Oracle?
--
Sent via pgsql-performance mailing list
Ray Stell ste...@cns.vt.edu writes:
On Thu, Aug 06, 2009 at 12:50:51PM +1000, Ip Wing Kin John wrote:
(running DTrace tool kit iofile.d script to show I/O wait time by
filename and process)
Is the dtrace toolkit a viable product for a linux environment or
is it strickly Sun/Oracle?
dtrace
On Thu, Aug 06, 2009 at 11:01:52AM -0400, Tom Lane wrote:
dtrace is available on Solaris and Mac OS X and probably a couple
other platforms, but not Linux.
I wondered if anyone had given this a go:
http://amitksaha.blogspot.com/2009/03/dtrace-on-linux.html
--
Sent via pgsql-performance
I wasn't able to compile dtrace on either CentOS 5.3 or Fedora 11. But
the author is responsive and the problem doesn't look hard to fix. It
sits in my inbox awaiting some hacking time...
Ken
On Thu, 06 Aug 2009 11:43:05 -0400, Ray Stell ste...@cns.vt.edu wrote:
On Thu, Aug 06, 2009 at
On Thu, 2009-08-06 at 11:57 -0400, Kenneth Cox wrote:
I wasn't able to compile dtrace on either CentOS 5.3 or Fedora 11. But
the author is responsive and the problem doesn't look hard to fix. It
sits in my inbox awaiting some hacking time...
Why aren't you using systemtap again? As I
On Thu, Aug 06, 2009 at 09:12:22AM -0700, Joshua D. Drake wrote:
Why aren't you using systemtap again?
1. significant solaris responsibilites
2. significant linux responsibilities
3. tool consolidation delusions
Can you drive dtace toolkit via systemtap?
--
Sent via pgsql-performance mailing
On Thu, 2009-08-06 at 12:38 -0400, Ray Stell wrote:
On Thu, Aug 06, 2009 at 09:12:22AM -0700, Joshua D. Drake wrote:
Why aren't you using systemtap again?
1. significant solaris responsibilites
There is your problem right there ;)
2. significant linux responsibilities
3. tool
On Wed, Aug 5, 2009 at 8:50 PM, Ip Wing Kin Johnwkipj...@gmail.com wrote:
I have a database (699221). It contains of 1.8GB data (707710). I am
doing a complex query. Which required to load a 80MB index (732287).
I restarted Postgresql so the cache is empty and it has to read the
table and
Hi Scott,
Yes I did that. And you are right because I restart my machine, so the
postgres cache is empty. And I think postgresql is reading all 1.8GB of
data back into the cache when it does a seq scan on the status table.
QUERY PLAN
Could you possibly attach that in plain text format? Your email
client seems to have eaten any text formatting / indentation.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Is this alright?
QUERY PLAN
---
Sort (cost=390162.53..390162.54 rows=3 width=567) (actual
time=106045.453..106
Sorry post again.
QUERY PLAN
---
Sort (cost=390162.53..390162.54 rows=3 width=567) (actual
time=105726.803..105
18 matches
Mail list logo
