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
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
21 matches
Mail list logo
