From: | "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andreas Joseph Krogh" <andreak(at)officenet(dot)no>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Including Snapshot Info with Indexes |
Date: | 2007-10-13 12:14:12 |
Message-ID: | 9362e74e0710130514o2e84b90eucbf31a38b913ee1f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Hi,
I went through this article and it was good. Please have a look at it.
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
This article was written by Michael Stonebraker, considered to be the
founder of our database. He has mentioned that the DBMS designed in 1970s
haven't changed according to the change that has happened in Hardware
landscape. The Vertica database(Monet is a open source version with the same
principle) makes use of the very same principle. Use more disk space, since
they are less costly and optimize the data warehousing.
Even otherwise we are recommending Indexes with snapshot as an option. We
are not replacing the current index scheme. So if someone feels that his
database should run on lesser disk space, let them create the normal index.
If he feels he can afford to have more redundant disk space, then he can
create indexes with snapshots. We are reducing random I/Os at the cost of
extra disk space. So definitely that's a good. But tech folks like us can
better decide on something based on experiments, as Tom has pointed out. So
let's see whether Indexes with snapshot is worth the trade-off in space.
Thanks,
Gokul.
On 10/13/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
>
> "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> writes:
>
> > I accept that the indexes will be bigger in size for this approach. You
> > might need more disk-space and you might need more memory to accomodate
> the
> > same amount of information. But i think disk costs and memory costs have
> > come down a lot, People can afford to buy more disk and memory.
>
> That's not how it works. We're not generally worried about people running
> out
> of disk or memory resources. But no matter how cheap they get people will
> only
> have what they have. We have to worry about running as fast as possible
> for a
> *given* amount of RAM or disk.
>
> Generally raising disk space usage results in a corresponding increase in
> run
> time. So an index that takes twice as much space on disk will consume
> twice as
> much time to consult as one that doesn't. You need to save enough time
> elsewhere to make that up and then some to make it worthwhile.
>
> I think we are pretty set on having the DSM for vacuuming purposes so
> you'll
> also have to argue this approach will cover enough additional cases or be
> better in some other way compared to using the DSM to be a win.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2007-10-13 12:23:13 | Re: Including Snapshot Info with Indexes |
Previous Message | Gregory Stark | 2007-10-13 09:22:11 | Re: Including Snapshot Info with Indexes |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2007-10-13 12:23:13 | Re: Including Snapshot Info with Indexes |
Previous Message | Gregory Stark | 2007-10-13 09:22:11 | Re: Including Snapshot Info with Indexes |