I have added URLs to your patch to the TODO list:
* Allow data to be pulled directly from indexes
---
Gokulakannan Somasundaram wrote:
Hi,
I would like to present the first patch. It currently has the
On Jan 28, 2008 8:21 AM, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
I am not seeing my mail getting listed in the archives. So i am just
resending it, in case the above one has got missed.
It was sent. Archive processing is delayed.
--
Jonah H. Harris, Sr. Software Architect | phone:
On 10/28/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, R, 2007-10-26 kell 16:46, kirjutas Gokulakannan
Somasundaram:
What does the numbers look like if the the tables are small
enough to
fit in RAM?
I don't know whether this is a valid
Ühel kenal päeval, R, 2007-10-26 kell 16:46, kirjutas Gokulakannan
Somasundaram:
What does the numbers look like if the the tables are small
enough to
fit in RAM?
I don't know whether this is a valid production setup, against which
we need to benchmark.
Often the
Gokulakannan Somasundaram wrote:
As far as Load Test is concerned, i have tried to provide all the relevant
details. Please inform me, if i have left any.
Thanks!
How large were the tables?
Did you run all the queries concurrently? At this point, I think it'd be
better to run them separately
On 10/26/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
As far as Load Test is concerned, i have tried to provide all the
relevant
details. Please inform me, if i have left any.
Thanks!
How large were the tables?
It is in the Performance test report.
Gokulakannan Somasundaram wrote:
On 10/26/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
As far as Load Test is concerned, i have tried to provide all the
relevant
details. Please inform me, if i have left any.
Thanks!
How large were the tables?
It is
On 10/26/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
On 10/26/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
As far as Load Test is concerned, i have tried to provide all the
relevant
details. Please inform me, if i
This has been saved for consideration for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Gokulakannan Somasundaram wrote:
Hi,
I would like to present the first patch. It currently
Ü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
Gokulakannan Somasundaram wrote:
I would like to present the first patch. It currently has the following
restrictions
a) It does not support any functional indexes.
b) It supports queries like select count(1) from table where (restrictions
from indexed columns), but it does not support
On 10/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
I would like to present the first patch. It currently has the
following
restrictions
a) It does not support any functional indexes.
b) It supports queries like select count(1) from table where
Please keep the list cc'd.
Gokulakannan Somasundaram wrote:
On 10/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
I have also enabled the display of Logical Reads. In order to see that,
set
log_statement_stats on.
You should start benchmarking, to verify
On 10/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Please keep the list cc'd.
Gokulakannan Somasundaram wrote:
On 10/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
I have also enabled the display of Logical Reads. In order to see that,
set
Gokulakannan Somasundaram wrote:
Say, with a normal index, you need to goto the table for checking the
snapshot. So you would be loading both the index pages + table pages, in
order to satisfy a certain operations. Whereas in thick index you occupy 16
bytes per tuple more in order to avoid
On 10/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gokulakannan Somasundaram wrote:
Say, with a normal index, you need to goto the table for checking the
snapshot. So you would be loading both the index pages + table pages, in
order to satisfy a certain operations. Whereas in thick
Ühel kenal päeval, T, 2007-10-23 kell 13:04, kirjutas Heikki
Linnakangas:
Gokulakannan Somasundaram wrote:
Say, with a normal index, you need to goto the table for checking the
snapshot. So you would be loading both the index pages + table pages, in
order to satisfy a certain operations.
On 10/23/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, T, 2007-10-23 kell 13:04, kirjutas Heikki
Linnakangas:
Gokulakannan Somasundaram wrote:
Say, with a normal index, you need to goto the table for checking the
snapshot. So you would be loading both the index pages +
Hannu Krosing wrote:
I would suggest that you use just an additional heap with decoupled
visibility fields as DSM.
Yeah, I remember you've suggested that before, and I haven't responded
this far. The problems I see with that approach are:
1) How do you know which visibility info corresponds
Ühel kenal päeval, T, 2007-10-23 kell 18:36, kirjutas Gokulakannan
Somasundaram:
There are several advantages to keeping a separate visibility
heap:
1) it is usually higly compressible, at least you can throw
away
cmin/cmax quite
Ühel kenal päeval, T, 2007-10-23 kell 14:16, kirjutas Heikki
Linnakangas:
Hannu Krosing wrote:
I would suggest that you use just an additional heap with decoupled
visibility fields as DSM.
Yeah, I remember you've suggested that before, and I haven't responded
this far. The problems I see
On 10/23/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, T, 2007-10-23 kell 18:36, kirjutas Gokulakannan
Somasundaram:
There are several advantages to keeping a separate visibility
heap:
1) it is usually higly compressible, at least you can throw
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
Hi,
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.
a) There can be index only scans like Oracle
b) Unique indexes will become less
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
72 matches
Mail list logo
