Hi all..
Can any one help me?
I'd like to know how can we get the following information in
PostgreSQL:
Execution plan
The I/O physical reads and logical reads, CPU consumption, number of
DB block used, and any other information relevant to performance.
Taking into consideration that these
Reading this thread confuses me a little bit. There is no need to backup
a cluster in order to move it to another disk within the same machine.
Stopping the Database, moving $PGDATA, adjusting scripts and routines if
nessecary and firing up the whole thing would do fine.
regards
-Andreas
On Thu, Jul 22, 2010 at 10:10 PM, std pik std...@gmail.com wrote:
Hi all..
Can any one help me?
I'd like to know how can we get the following information in
PostgreSQL:
Execution plan
explain your query here
explain analyze your query here
explain just shows the plan, explain analyze shows
I've dont only cursory research on this so far, so thought I'd ask here
first...
Does anyone know of any ftp client capabilities in Postgresql, any prebuilt
functions or extensions already built?
Or is it a roll-your-own kind of thing?
Thanks, Lou
On 07/23/2010 09:58 AM, Lou Picciano wrote:
I've dont only cursory research on this so far, so thought I'd ask here
first...
Does anyone know of any ftp client capabilities in Postgresql, any
prebuilt functions or extensions already built?
Or is it a roll-your-own kind of thing?
plperl
On Fri, Jul 23, 2010 at 10:58 AM, Lou Picciano loupicci...@comcast.net wrote:
I've dont only cursory research on this so far, so thought I'd ask here
first...
Does anyone know of any ftp client capabilities in Postgresql, any prebuilt
functions or extensions already built?
Or is it a
Thanks, Scott, for that. I've already experimented a little from doing ftp
calls from straight from shell - using PL/sh - of course, this is
sub-optimal(!), but was good for an experiment.
Having trouble so far getting PL/php built on v9, too...
OK, we'll keep at it!
- Original
Joe, thanks for that suggestion. I'll try it. I'd imagined any internal
function would have to wrestle with encapsulating the communications - async?
delays? - within a function process. Probably not too easy.
Lou
- Original Message -
From: Joe Conway m...@joeconway.com
To: Lou
Greg Smith g...@2ndquadrant.com writes:
In news I don't consider unrelated, FreeBSD is now working on adding DTrace
support:
http://freebsdfoundation.blogspot.com/2010/06/dtrace-userland-project.html
which will give me yet another reason to consider deploying on that OS
instead of Linux.