Kevin Grittner wrote:
I know this issue on this thread has come up at least one or two
other times lately:
http://archives.postgresql.org/pgsql-performance/2007-08/msg00113.php
I know it's a largely independent issue, but your comment about the
API not giving access to the index tuples echoe
>>> On Wed, Nov 7, 2007 at 3:13 PM, in message
<[EMAIL PROTECTED]>, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
> On Tue, Nov 6, 2007 at 8:18 AM, in message <[EMAIL PROTECTED]>,
>> Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>>
>>> The indexam API needs to be m
Kevin Grittner wrote:
On Tue, Nov 6, 2007 at 8:18 AM, in message <[EMAIL PROTECTED]>,
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
The indexam API needs to be modified as well, because there's currently
no API to return index tuples from an index.
I know this is tangential, but expanding
>>> On Tue, Nov 6, 2007 at 8:18 AM, in message <[EMAIL PROTECTED]>,
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> The indexam API needs to be modified as well, because there's currently
> no API to return index tuples from an index.
I know this is tangential, but expanding the types of sel
Jeff Davis wrote:
On Mon, 2007-11-05 at 22:45 +, Heikki Linnakangas wrote:
1) Do as you say above. What are some of the cost trade-offs here? It
seems that frequent VACUUM FREEZE runs would keep the visibility map
mostly full, but will also cause more writing. I suppose the worst case
is tha
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I don't buy that. I believe at least on some architectures you'd get a
> word-long load+modify+store, and scribble the neighboring bytes.
Hm, I mis-remembered this bit of advice from the glibc info doc. I remembered
thinking it was strange when I
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> For example, if there is a query like select count(1) from table. Then
> we can scan through all the index pages and the visibility map to get
> the count. Currently it goes for Full table scan. there should be
> something like full index
On Tue, 2007-11-06 at 08:01 -0500, Mark Mielke wrote:
> Simon Riggs wrote:
> > On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> > I'm racking my brain trying to think of a query that will benefit from
> > index-only scans without specifically creating covered indexes. Apart
> > from c
On Mon, 2007-11-05 at 22:45 +, Heikki Linnakangas wrote:
> > 1) Do as you say above. What are some of the cost trade-offs here? It
> > seems that frequent VACUUM FREEZE runs would keep the visibility map
> > mostly full, but will also cause more writing. I suppose the worst case
> > is that eve
By the way, please have a look at how i have converted a index scan
into a index only scan in the thick index patch. Currently it doesn't
convert those queries which doesn't have where clause. I hope you
would be able refine it further.
For example, if there is a query like select count(1) from tab
Gokulakannan Somasundaram wrote:
On Nov 6, 2007 4:33 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Gokulakannan Somasundaram wrote:
Just one more thought on the same. This implementation also assumes
that there won't be any update chains across pages, which is the
current stage.
No, it doe
On Nov 6, 2007 4:33 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Gokulakannan Somasundaram wrote:
> > Just one more thought on the same. This implementation also assumes
> > that there won't be any update chains across pages, which is the
> > current stage.
>
> No, it doesn't assume that.
S
Simon Riggs wrote:
On Tue, 2007-11-06 at 13:29 +, Heikki Linnakangas wrote:
And of course people will start adding columns to indexes, to make use
of index-only-scans, once we have the capability.
Not too keen on that. Very difficult to judge whether its worth the
benefit for creati
Simon Riggs wrote:
I'm thinking that looking in the visibility map will have a cost also,
so how will we know whether to bother looking? I'm assuming that we
won't want to do that lookup in all cases, since it could easily just
add pathlength and contention in the normal OLTP case.
Yeah, I beli
On Tue, 2007-11-06 at 13:29 +, Heikki Linnakangas wrote:
> > My list would be:
> > - EXISTS / NOT EXISTS
> > - COUNT(*)
>
> Yeah, those are good candidates.
Yeah.
> Many-to-many relationships is one example:
OK, thats a very good one.
> And of course people will start adding columns to in
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
One problem is that you have to atomically update the visibility map when
you update the heap. That means that you have to lock the visibility map
page and the heap page at the same time. If the visibility map is in the
heap,
On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
> > On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> >> (Gosh, we really need a name for the sort of vacuum. I was about to say
> >> "we'd still need regular regular VACUUMs" :-))
> >
> > As the new VACUUM var
Mark Mielke wrote:
Simon Riggs wrote:
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
I'm racking my brain trying to think of a query that will benefit from
index-only scans without specifically creating covered indexes. Apart
from count(*) queries and RI lookups. I can't see RI loo
Marko Kreen wrote:
On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
(Gosh, we really need a name for the sort of vacuum. I was about to say
"we'd still need regular regular VACUUMs" :-))
As the new VACUUM variant will be somewhat unsafe, it should
not replace "regular" VACUUM but get
On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Jeff Davis wrote:
> > On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> >> It's not useful for VACUUM FREEZE, unless we're willing to freeze much
> >> more aggressively, and change the meaning of a set bit to "all tuples on
>
On 11/6/07, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Simon Riggs wrote:
> > On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> > I'm racking my brain trying to think of a query that will benefit from
> > index-only scans without specifically creating covered indexes. Apart
> > from coun
Mark Mielke wrote:
I'm not sure what RI lookup is. Sorry. :-)
RI = Referential Integrity. i.e. Foreign Keys.
cheers
andrew
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Simon Riggs wrote:
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
I'm racking my brain trying to think of a query that will benefit from
index-only scans without specifically creating covered indexes. Apart
from count(*) queries and RI lookups. I can't see RI lookups being much
chea
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> Reducing VACUUM time is important, but the real big promise is the
> ability to do index-only-scans.
Have you thought about how index-only scans work work? Seems like we
need a rough plan for that before we go and build the visibili
Gokulakannan Somasundaram wrote:
Just one more thought on the same. This implementation also assumes
that there won't be any update chains across pages, which is the
current stage.
No, it doesn't assume that.
Heikki,
Is it planned as a optional feature? (I support the optional
feature
Just one more thought on the same. This implementation also assumes
that there won't be any update chains across pages, which is the
current stage.
Heikki,
Is it planned as a optional feature? (I support the optional
feature model)
Thanks,
Gokul.
On Nov 6, 2007 12:20 PM, Gregory Stark <[
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> One problem is that you have to atomically update the visibility map when
> you update the heap. That means that you have to lock the visibility map
> page and the heap page at the same time. If the visibility map is in the
> heap, you need to tak
Jeff Davis wrote:
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
It's not useful for VACUUM FREEZE, unless we're willing to freeze much
more aggressively, and change the meaning of a set bit to "all tuples on
heap page are frozen".
This means that a regular VACUUM will no longer
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Though 8.3 isn't out of the oven just yet, I've been thinking about the
dead space map a lot, and decided I have to start writing down those
thoughts.
I think we should do this at the same time as pushing the FSM out of
shared mem
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Though 8.3 isn't out of the oven just yet, I've been thinking about the
> dead space map a lot, and decided I have to start writing down those
> thoughts.
I think we should do this at the same time as pushing the FSM out of
shared memory, and desi
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> Reducing VACUUM time is important, but the real big promise is the
> ability to do index-only-scans. Because that's the main focus of this
> exercise, I'm calling it the the Visibility Map from now on, because
> it's not about tracki
On 11/5/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > a) The inserts won't increase the size of the table. If it increases, it
> has
> > to lock one full page of Visibility map and this is not suitable for
> tables,
> > which are short-lived like partiti
Gokulakannan Somasundaram wrote:
a) The inserts won't increase the size of the table. If it increases, it has
to lock one full page of Visibility map and this is not suitable for tables,
which are short-lived like partitioned tables
The overhead of locking a page is very small.
Actually, exten
This is my feedback regarding the Visibility map.
I just want to disagree on the fact that the DSM/Visibility map would not
focus on Vacuum. I think Index only scans should be thought of as a fringe
benefit of DSMs/ Visibility Maps. There are some basic assumptions in the
design, which says that
a
Though 8.3 isn't out of the oven just yet, I've been thinking about the
dead space map a lot, and decided I have to start writing down those
thoughts.
Reducing VACUUM time is important, but the real big promise is the
ability to do index-only-scans. Because that's the main focus of this
exerc
35 matches
Mail list logo
