Hi All,
I want some clarification in the following,
In a database which we are having we have nearly 100 tables, and in 75% of
the tables we have 6 columns ( INT ) as standard columns. What is standard
columns, if you create a table in this database you should have some default
6 columns in there
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:
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
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(*) fro
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 ".
Well, the table has been analyzed, I did SELECT, PG write on the
"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 o
"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
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 wit
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
