On Thu, Mar 20, 2008 at 8:32 PM, Chris Hoover [EMAIL PROTECTED] wrote:
I just found out that my company is planning on migrating my databases from
our current ISCSI storage solution to NetApps connected via NFS. I knew
about the NetApp migration, but always assumed (and shame on me) that I
2008/3/20, Tom Lane [EMAIL PROTECTED]:
Another way that SELECT can cause disk writes is if it sets hint bits on
recently-committed rows. However, if the tables aren't actively being
modified any more, you'd expect that sort of activity to settle out pretty
quickly.
I concur with the
Dawid Kuroczko [EMAIL PROTECTED] writes:
It is also possible to present block devices from NetApp over iSCSI or FC
(I am not sure about licensing model though). You get all the goodies
like thin provisioning (only non-zero blocks are allocated), snapshots and
all, but you see it as a block
Laurent Raufaste [EMAIL PROTECTED] writes:
All this make me think that PG was setting some bit on every row it
used, which caused this massive write activity (3MB/s) in the table
files. I'm talking about approx. 50 SELECT per second for a single
server.
Well that's true it does. But only
2008/3/21, Gregory Stark [EMAIL PROTECTED]:
Well that's true it does. But only once per row. So analyze would have set the
bit on every row. You could do the same thing with something ligter like
select count(*) from table.
Well, the table has been analyzed, I did SELECT, PG write on the
In response to Laurent Raufaste [EMAIL PROTECTED]:
2008/3/21, Gregory Stark [EMAIL PROTECTED]:
Well that's true it does. But only once per row. So analyze would have set
the
bit on every row. You could do the same thing with something ligter like
select count(*) from table.
Well,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Aside from what's said there, I'd note that it's a seriously bad idea
to use a soft mount or any arrangement wherein it's possible for
Postgres to be running while the NFS disk is not mounted.
Do the docs need
Added to TODO:
* Improve performance of shared invalidation queue for multiple CPUs
http://archives.postgresql.org/pgsql-performance/2008-01/msg00023.php
---
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
