On Sat, 2005-04-23 at 15:04 -0700, Ron Mayer wrote:
> Bruce Momjian wrote:
> > See this TODO: * Allow data to be pulled directly from indexes
> > I think this is the direction we should be heading because it has more
> > general usefulness.
>
> I think read-only tables would have a few different
I send it now the 3rd time because I'm not sure my mail works, as it has not
appeared on pgsql-hackers
On L, 2005-04-23 at 18:27 -0400, Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > Is this a fair summary of the potential benefits of READ-ONLY
> > tables? (from both this thread and
On 4/24/05, Tom Lane wrote:
>
> What you are talking about is not a "read only" table, it is a
> "non-MVCC" table. This is a much greater assault on the fundamental
> semantics of Postgres than it's being painted to be in this thread.
> In particular, how is such a table going to come into being?
On L, 2005-04-23 at 00:02 -0400, Bruce Momjian wrote:
> Russell Smith wrote:
...
> > I know especially for some tables, I would choose this index with
> > visibility as it would increase performance by not looking at the table
> > at all for that information (count being a good example). However f
On R, 2005-04-22 at 13:14 -0400, Bruce Momjian wrote:
> > This can be prohibitively pricey for big tables with lots of indexes, as
> > marking the tuple means alsn finding and possibly writing to all index
> > enytries pointing to this tuple.
>
> Yep, it could be very ugly, but it would help with
On L, 2005-04-23 at 18:27 -0400, Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > Is this a fair summary of the potential benefits of READ-ONLY
> > tables? (from both this thread and the archives):
>
> > 1. Index-only scans are made possible fairly easily because
> > you wouldn
2. Simple tables can be much smaller since you don't need
most of the HeapTupleHeaderData.
What you are talking about is not a "read only" table, it is a
"non-MVCC" table. This is a much greater assault on the fundamental
semantics of Postgres than it's being painted to be in this thr
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> One idea that may be closer to reality might be implementing heaps that
> behave as indexes (or indexes that behave as heaps), or clustered
> indexes as some other database call them; the main idea being that at
> the leaf nodes of the index, the whole h
On Sat, Apr 23, 2005 at 06:27:38PM -0400, Tom Lane wrote:
> While I don't say it's impossible to do, I do think that the work and
> semantic ugliness involved would outweigh the possible benefits. In
> particular, there are other, more transparent ways of doing #1.
One idea that may be closer to
Ron Mayer <[EMAIL PROTECTED]> writes:
> Is this a fair summary of the potential benefits of READ-ONLY
> tables? (from both this thread and the archives):
> 1. Index-only scans are made possible fairly easily because
> you wouldn't need to check the heap for visibility.
> 2. Simple tab
Simon Riggs wrote:
As Ron says, until we have partitioning, it isn't as useful for DW.
Well, it's a bit stronger than what I said. The last big DW I dealt
with did have previous quarter's data archived into different tables,
and those could be marked read-only. Also, quite a few of our
ID<->Valu
Bruce Momjian wrote:
See this TODO: * Allow data to be pulled directly from indexes
I think this is the direction we should be heading because it has more
general usefulness.
I think read-only tables would have a few different types
of general usefulness in addition to enabling index scans.
Is thi
See this TODO:
* Allow data to be pulled directly from indexes
Currently indexes do not have enough tuple visibility information
to allow data to be pulled from the index without also accessing
the heap. One way to allow this is to set a bit
Fetching data from just indexes has been discussed on this list several
times before, and it has been told that this can't be done with postgres
thanks to MVCC.
But this is true only when data is changing. In a data-warehousing
scenario what it is often needed is a possibility for fast querying o
You should read the archives of this list; there was a pretty long
thread about this a few months ago. IIRC the consensus after much debate
was that this feature would add benefit in many instances, especially on
large tables where only a small amount of data changes.
Also, I think there is value
Russell Smith wrote:
> On Sat, 23 Apr 2005 03:14 am, Bruce Momjian wrote:
> > Hannu Krosing wrote:
> > > On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> > > > See this TODO:
> > > >
> > > > * Allow data to be pulled directly from indexes
> > > >
> > > >Currently indexes do not have eno
On Sat, 23 Apr 2005 03:14 am, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> > > See this TODO:
> > >
> > > * Allow data to be pulled directly from indexes
> > >
> > >Currently indexes do not have enough tuple visibility information
Fetching data from just indexes has been discussed on this list several
times before, and it has been told that this can't be done with postgres
thanks to MVCC.
But this is true only when data is changing. In a data-warehousing
scenario what it is often needed is a possibility for fast querying of
Hannu Krosing wrote:
> On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> > See this TODO:
> >
> > * Allow data to be pulled directly from indexes
> >
> > Currently indexes do not have enough tuple visibility information
> > to allow data to be pulled from the index w
On R, 2005-04-22 at 11:40 -0400, Bruce Momjian wrote:
> See this TODO:
>
> * Allow data to be pulled directly from indexes
>
> Currently indexes do not have enough tuple visibility information
> to allow data to be pulled from the index without also accessing
>
On 4/22/05, Hannu Krosing wrote:
> Fetching data from just indexes has been discussed on this list several
> times before, and it has been told that this can't be done with postgres
> thanks to MVCC.
>
> But this is true only when data is changing. In a data-warehousing
> scenario what it is often
On Fri, 2005-04-22 at 18:34 +0300, Hannu Krosing wrote:
> Fetching data from just indexes has been discussed on this list several
> times before, and it has been told that this can't be done with postgres
> thanks to MVCC.
>
> But this is true only when data is changing. In a data-warehousing
> sc
Jochem van Dieten wrote:
On 4/22/05, Hannu Krosing wrote:
...But this is true only when data is changing. In a data-warehousing
scenario what it is often needed is a possibility for fast querying of
static historical data.
And when we get partitioning, I think many data warehouses will have
the bul
23 matches
Mail list logo
