Ühel kenal päeval, L, 2007-10-20 kell 10:19, kirjutas Luke Lonergan:
Hi Hannu,
On 10/14/07 12:58 AM, Hannu Krosing [EMAIL PROTECTED] wrote:
What has happened in reality, is that the speed difference between CPU,
RAM and disk speeds has _increased_ tremendously
Yes.
which makes it
Hi,
I have tested with makeing this change and it is showing useful
readings. The point of introducing the indexes with snapshot is that it
should reduce the number of logical I/Os.(It may be from memory / from hard
disk). Logical I/Os are potential Physical I/Os.
On 10/20/07, Martijn van
On Sat, Oct 20, 2007 at 09:24:07AM +0530, Gokulakannan Somasundaram wrote:
Hi,
I think i have a initial Implementation. It has some bugs and i am working
on fixing it. But to show the advantages, I want to show the number of
Logical I/Os on the screen. In order to show that, i tried enabling
Hi Hannu,
On 10/14/07 12:58 AM, Hannu Krosing [EMAIL PROTECTED] wrote:
What has happened in reality, is that the speed difference between CPU,
RAM and disk speeds has _increased_ tremendously
Yes.
which makes it even
more important to _decrease_ the size of stored data if you want good
Hi,
I think i have a initial Implementation. It has some bugs and i am working
on fixing it. But to show the advantages, I want to show the number of
Logical I/Os on the screen. In order to show that, i tried enabling the
log_statement option in PostgreSQL.conf. But it shows only the physical
Ühel kenal päeval, L, 2007-10-13 kell 17:44, kirjutas Gokulakannan
Somasundaram:
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
A Dissabte 13 Octubre 2007, Gokulakannan Somasundaram va escriure:
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
On 10/14/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, L, 2007-10-13 kell 17:44, kirjutas Gokulakannan
Somasundaram:
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
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
So Indexes with snapshots will be degrading the performance only for deletes
and only those updates, which are updating the index tuple.
Deletes never update indexes in Postgres. Increasing the size of the index
would affect vacuum, inserts,
On 10/14/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
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
On 10/14/07, Gregory Stark [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
So Indexes with snapshots will be degrading the performance only for
deletes
and only those updates, which are updating the index tuple.
Deletes never update indexes in Postgres.
On 10/14/07, Trevor Talbot [EMAIL PROTECTED] wrote:
On 10/14/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
The Vertica database(Monet is a open source version with the same
principle) makes use of the very same
On 10/12/07, Tom Lane [EMAIL PROTECTED] wrote:
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted feature.
If you mean count(*) will become instantaneous, no it won't. It would
get faster, but probably not by
Gokulakannan Somasundaram [EMAIL PROTECTED] 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,
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
On 10/13/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
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
On 10/13/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
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
Hi All,
So i think we are clear now, that it is possible to have an index
with snapshot info. Let me try to enumerate the uses of having the Index
with snapshot info, in comparison to the Dead Space Map.
a) Dead Space, if it is successfull in its implementation of what it claims,
will
Hi All,
Last mail was sent by mistake without completion. I apologize for
that. i am continuing on that.
So i think we are clear now, that it is possible to have an index with
snapshot info. Let me try to enumerate the uses of having the Index with
snapshot info, in comparison to the
Hi All,
Last two mails were sent by mistake without completion. I couldn't
curse my system any further
I apologize for that.
If we comeback to the topic of discussion
So i think we are clear now, that it is possible to have an index with
snapshot info. Let me try to
Gokulakannan Somasundaram wrote:
Last two mails were sent by mistake without completion. I couldn't
curse my system any further
:-)
a) Dead Space, if it is successfull in its implementation of what it claims,
will have the means to point out that all the tuples of certain chunks are
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted feature.
--
Andreas Joseph Krogh [EMAIL PROTECTED]
Senior Software Developer / Manager
+-+
OfficeNet AS| The most difficult thing in
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted feature.
If you mean count(*) will become instantaneous, no it won't. It would
get faster, but probably not by more than a factor of 10 or so,
corresponding to the
On 10/12/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
If records have just been inserted to a block, it is in cache. Therefore
hitting that block to check visibility isn't going to cost much. There
might be some middle-ground where a tuple has been inserted
Andreas Joseph Krogh wrote:
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted feature.
Yes, both the DSM approach and the approach proposed by Gokul.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
On Friday 12 October 2007 11:49:17 Heikki Linnakangas wrote:
Andreas Joseph Krogh wrote:
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted feature.
Yes, both the DSM approach and the approach proposed by Gokul.
Good.
--
Andreas Joseph Krogh [EMAIL PROTECTED]
I agree with that. I will go ahead and do a test implementation and share
the results with everyone.
Thanks,
Gokul.
On 10/12/07, Tom Lane [EMAIL PROTECTED] wrote:
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted
Gokulakannan Somasundaram wrote:
As explained, if we are going to include the snapshot with indexes, Vacuum
will be done on the index independent of the table, so Vacuum will not
depend on immutability. We need to goto the index from the table, when we
want to update the snapshot info. The
On 10/9/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Andrew Dunstan wrote:
Florian G. Pflug wrote:
I think you're overly pessimistic here ;-) This classification can be
done
quite efficiently as long as your language is static enough. The
trick is
not to execute the function, but to
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
I am always slightly late in understanding things. Let me
try
to understand the use of DSM. It is a bitmap index on whether all the
tuples
in a particular block is visible to all the
On 10/8/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
Hi Heikki, I am always slightly late in understanding things. Let me
try to understand the use of DSM. It is a bitmap index on whether all
the tuples in a particular block is visible to all the backends,
On 10/9/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
I am always slightly late in understanding things. Let me
try
to understand the use of DSM. It is a bitmap index on
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
On 10/9/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
A function is said to be deterministic, if it returns the same value,
irrespective of how many times, it is invoked. I think this definition
clearly puts the random function
[snip]
In the case of User-Defined functions, the user should be defining it
as Deterministic.
The user CAN already define his functions as
Deterministic=IMMUTABLE... the problem is that many of us will define
functions as immutable, when in fact they are not. And do that by
mistake... and
Csaba Nagy wrote:
Can we frame a set of guidelines, or may be some test procedure, which
can declare a certain function as deterministic?
You mean postgres should check your function if it is really immutable ?
I can't imagine any way to do it correctly in reasonable time :-)
Imagine a
I think you're overly pessimistic here ;-) This classification can be done
quite
efficiently as long as your language is static enough. The trick is not to
execute the function, but to scan the code to find all other functions and
SQL
statements a given function may possibly call. If
Csaba Nagy wrote:
You mean postgres should check your function if it is really immutable ?
I can't imagine any way to do it correctly in reasonable time :-)
I would say that in the general case it's analogous to the halting
problem, not solvable at all let alone in any reasonable
Florian G. Pflug wrote:
I think you're overly pessimistic here ;-) This classification can be
done quite efficiently as long as your language is static enough.
The trick is not to execute the function, but to scan the code to find
all other functions and SQL statements a given function may
On Tue, 2007-10-09 at 11:22 -0400, Andrew Dunstan wrote:
Csaba Nagy wrote:
You mean postgres should check your function if it is really immutable ?
I can't imagine any way to do it correctly in reasonable time :-)
I would say that in the general case it's analogous to the halting
Andrew Dunstan wrote:
Florian G. Pflug wrote:
I think you're overly pessimistic here ;-) This classification can be done
quite efficiently as long as your language is static enough. The trick is
not to execute the function, but to scan the code to find all other
functions and SQL statements a
Gokulakannan Somasundaram wrote:
Currently The index implementation in Postgresql does not store the
Snapshot information in the Index. If we add the snapshot information into
the indexing structure, we will have the following advantages.
This idea has been discussed to death many times
On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
This idea has been discussed to death many times before. Please search
the archives.
Somewhat related to the visibility in index thing: would it be
possible to have a kind of index-table ? We do have here some tables
which have 2-4
Csaba Nagy wrote:
On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
This idea has been discussed to death many times before. Please search
the archives.
Somewhat related to the visibility in index thing: would it be
possible to have a kind of index-table ? We do have here some
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
Currently The index implementation in Postgresql does not store the
Snapshot information in the Index. If we add the snapshot information
into
the indexing structure, we will have the following
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Csaba Nagy wrote:
On Mon, 2007-10-08 at 09:40 +0100, Heikki Linnakangas wrote:
This idea has been discussed to death many times before. Please search
the archives.
Somewhat related to the visibility in index thing: would it be
Gokulakannan Somasundaram wrote:
On 10/8/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
IMO, the most promising approach to achieving index-only-scans at the
moment is the Dead Space Map, as discussed in the 8.3 dev cycle.
Index only scans means that in order to get certain results, we may
Ühel kenal päeval, E, 2007-10-08 kell 11:41, kirjutas Heikki
Linnakangas:
The dead space map holds
visibility information in a condensed form. For index-only-scans, we
need to know if all tuples on page are are visible to us. If the dead
space map is designed with index-only-scans in mind, we
Hi Heikki,
I am always slightly late in understanding things. Let me try
to understand the use of DSM. It is a bitmap index on whether all the tuples
in a particular block is visible to all the backends, whether a particular
block contains tuples which are invisible to everyone. But i
Gokulakannan Somasundaram wrote:
Hi Heikki, I am always slightly late in understanding things. Let me
try to understand the use of DSM. It is a bitmap index on whether all
the tuples in a particular block is visible to all the backends,
whether a particular block contains tuples which are
Gokulakannan Somasundaram wrote:
I am always slightly late in understanding things. Let me try
to understand the use of DSM. It is a bitmap index on whether all the tuples
in a particular block is visible to all the backends, whether a particular
block contains tuples which are
50 matches
Mail list logo