On Tue, Aug 4, 2009 at 5:16 PM, Ibrahim
Harrani wrote:
> Hi,
>
> I am using postgresql 8.3 with FreeBSD. FreeBSD is using syslog by
> default for postgresql logs.
> I would like to disable syslog in postgresql.conf. Does this change
> increase the performance?
> What is the impact of using syslog o
On Thu, Aug 06, 2009 at 01:42:06PM -0500, Campbell, Lance wrote:
> PostgreSQL 8.3
> Linux RedHat 4.X
> 24G of memory
>
> When loading a file generated from pg_dumpall is there a key setting in
> the configuration file that would allow the load to work faster.
>
> Thanks,
>
> Lance Campbell
> Pro
On Thu, Aug 6, 2009 at 12:42 PM, Campbell, Lance wrote:
> PostgreSQL 8.3
> Linux RedHat 4.X
> 24G of memory
>
> When loading a file generated from pg_dumpall is there a key setting in the
> configuration file that would allow the load to work faster.
The ones I can think of are cranking up work_me
PostgreSQL 8.3
Linux RedHat 4.X
24G of memory
When loading a file generated from pg_dumpall is there a key setting in
the configuration file that would allow the load to work faster.
Thanks,
Lance Campbell
Project Manager/Software Architect/DBA
Web Services at Public Affairs
217-333-0382
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 cons
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 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 r
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 wrote:
On Thu, Aug 06, 2009 at 11:01:52AM -0400,
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-performanc
Ray Stell 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 is available
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 (p
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 fa
12 matches
Mail list logo
