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 follow
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 | pho
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 v
Ü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
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. P
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
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 t
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
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
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 leas
Ü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
Ü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 q
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 w
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 ind
Ü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 operatio
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 i
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:
>
> 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
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 benchmarkin
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
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 suppor
Ü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.
>
> >
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 Oo
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 g
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 enabl
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
rea
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
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
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
"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, inse
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.h
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.
> I
Ü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
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
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
> com
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 cha
"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
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 proba
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
>
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 th
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 in
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 PRO
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 broadc
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 t
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
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 en
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 Dea
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 ha
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
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
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
>
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 ma
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 time.
> 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
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 functio
[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
"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
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
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
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
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
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 invisib
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
Ü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,
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
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
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 fo
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 her
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
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
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 cost
72 matches
Mail list logo
