Re: Including Snapshot Info with Indexes - Mailing list pgsql-hackers
| From | Gokulakannan Somasundaram |
|---|---|
| Subject | Re: Including Snapshot Info with Indexes |
| Date | |
| Msg-id | 9362e74e0710130514o2e84b90eucbf31a38b913ee1f@mail.gmail.com Whole thread Raw |
| In response to | Re: Including Snapshot Info with Indexes (Gregory Stark <stark@enterprisedb.com>) |
| Responses |
Re: Including Snapshot Info with Indexes
Re: Including Snapshot Info with Indexes Re: Including Snapshot Info with Indexes |
| List | pgsql-hackers |
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.
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@enterprisedb.com> wrote:
"Gokulakannan Somasundaram" <gokul007@gmail.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
pgsql-hackers by date: