On Mon, Apr 11, 2005 at 10:59:51AM -0700, Joe Conway wrote:
> >FWIW, if I were to do this anew, I would probably opt for iSCSI over GigE
> >with
> >a NetApp.
>
> Any particular reason? Our NetApp technical rep advised nfs over iSCSI,
> IIRC because of performance.
I would mount the Netapp volum
Neil Conway wrote:
Keith Worthington wrote:
-> Seq Scan on tbl_current (cost=0.00..1775.57 rows=76457
width=31) (actual time=22.870..25.024 rows=605 loops=1)
This rowcount is way off -- have you run ANALYZE recently?
-Neil
---(end of broadcast)--
Aditya wrote:
On Mon, Apr 11, 2005 at 10:59:51AM -0700, Joe Conway wrote:
Any particular reason? Our NetApp technical rep advised nfs over iSCSI,
IIRC because of performance.
I would mount the Netapp volume(s) as a block level device on my server
using
iSCSI (vs. a file-based device like NFS) so
Here is the config for the AS4 server.
# -
# PostgreSQL configuration file
# -
#
# This file consists of lines of the form:
#
# name = value
#
# (The '=' is optional.) White space may be used. Comments are introduced
# with '#' anywhere on
Aditya wrote:
We have not, AFAICT, had any problems with the traffic over NFS as far as
reliability -- I'm sure there is a performance penalty, but the reliability
and scalability gains more than offset that.
My experience agrees with yours. However we did find one gotcha -- see
the thread startin
I am running 8.0.1 on a desktop xp system and a AS4 redhat system.
The redhat will be my production server in a week or so and it is returning
slower the my desk top?
I understand about the perc cards on the Dell (redhat) but my Dell 2 proc
box runs much faster (MSSQL) then my desktop, so I am wond
by Truncating the serverlog do you mean the data_log (as in my case)
log file of the postgresql sever ?. If thats the file you truncated
than i think its not a good habit..since you might need it at some
point of time for some debugging purpose in production.
You could use something like assuming
Well, a vacuum on the entire DB seemed to have cleaned things up.
No other user was logged into the server, and I certainly did not send
the signal.
I did clean up the serverlog file by truncating it ( > serverlog)
while the DB was running, I don't think it liked that since it crashed
the DB. I
...
>
> 2) Is there some (performance) difference between BEFORE and AFTER
>triggers? I believe there's no measurable difference.
>
BEFORE triggers might be faster, because you get a chance to reject the
record before it is inserted into table. Common practice is to put
validity checks into
