[PERFORM] postgresql on NFS.. recommended? not recommended?
hi, is it recommended to run a postgresql server on a nfs-share (gigabit-network)? so basically i have a NAS + a database-server, and wonder if i should put the database on local hard-drives in the db-server, or on the NAS, and mount it using NFS on the database-server. i haven't investigated the issue much yet (checked the mailing-list-archives, but couldn't find anything definitive.. ), so would like to hear opinions/recommendations? can the NAS solution be faster? how much is usually the NFS-overhead? or is there a consensus on this? saying for example "generally, you should never use NFS with postgresql?" or it depends on some factors? intuitively it seems to me that NFS will be always an extra overhead, but maybe it's an unmeasurably small overhead? thanks, gabor ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] postgresql on NFS.. recommended? not recommended?
On 10/8/07, Gábor Farkas <[EMAIL PROTECTED]> wrote: > hi, > > is it recommended to run a postgresql server on a nfs-share > (gigabit-network)? so basically i have a NAS + a database-server, > and wonder if i should put the database on local hard-drives in the > db-server, or on the NAS, and mount it using NFS on the database-server. > > i haven't investigated the issue much yet (checked the > mailing-list-archives, but couldn't find anything definitive.. ), so > would like to hear opinions/recommendations? > > can the NAS solution be faster? how much is usually the NFS-overhead? > > or is there a consensus on this? saying for example "generally, you > should never use NFS with postgresql?" or it depends on some factors? > > intuitively it seems to me that NFS will be always an extra overhead, > but maybe it's an unmeasurably small overhead? > > thanks, > gabor > > ---(end of broadcast)--- > TIP 9: In versions below 8.0, the planner will ignore your desire to >choose an index scan if your joining column's datatypes do not >match > This came up recently on pgsql-hackers. http://archives.postgresql.org/pgsql-hackers/2007-09/msg01182.php. See continuation of the thread here: http://archives.postgresql.org/pgsql-hackers/2007-10/msg00017.php - Josh/eggyknap ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PERFORM] Apache2 PostgreSQL http authentication
Tino Wildenhain wrote: > Magnus Hagander schrieb: >> I'd consider having a small daemon LISTENing for NOTIFYs that you send >> by triggers whenever the table has changed. That'll make sure it only >> dumps if something actually changed. And you can also implement some >> ratelimiting if needed. > Do you really think such a homegrown solution will be more > performant then just accessing postgres? If you have > many users the lookup time in a .htaccess/.htpasswd is not for > free either. Right, that's what it depends on. I'd measure it. In systems with not too many users (say just a couple of thousand), I've measured great improvements in speed. It depends on how you authenticate as well - if you authenticate every single http request, the difference is greater. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PERFORM] Apache2 PostgreSQL http authentication
Magnus Hagander schrieb: I'd consider having a small daemon LISTENing for NOTIFYs that you send by triggers whenever the table has changed. That'll make sure it only dumps if something actually changed. And you can also implement some ratelimiting if needed. Do you really think such a homegrown solution will be more performant then just accessing postgres? If you have many users the lookup time in a .htaccess/.htpasswd is not for free either. Regards Tino ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
