On 3/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I do not think you can assume that the plan won't be used later with
some older snapshot. Consider recursive plpgsql functions for a
counterexample: the inner occurrence might be the first to arrive at
a given line of the function, hence the firs
On 3/31/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Fri, 2007-03-30 at 13:54 -0400, Tom Lane wrote:
>
> Hm. So anytime we reject a potentially useful index as being not valid
> yet, we mark the plan as "only good for this top-level transaction"?
> That seems possibly workable --- in particul
On Fri, 2007-03-30 at 13:54 -0400, Tom Lane wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > Actually, if we are using Serializable Snapshot then there is no chance
> > to replan the query before the transaction completes and the next
> > transaction to start in the session must see the in
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Actually, if we are using Serializable Snapshot then there is no chance
> to replan the query before the transaction completes and the next
> transaction to start in the session must see the index and hence
> we must replan. So it would be enough just
Pavan Deolasee wrote:
On 3/30/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
My idea was to store a list of xid's together with the cached plan that
are assumed to be uncommitted accoring to the IndexSnapshot. The query
is replanned if upon execution the IndexSnapshot assumes that one of
these
On 3/30/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
My idea was to store a list of xid's together with the cached plan that
are assumed to be uncommitted accoring to the IndexSnapshot. The query
is replanned if upon execution the IndexSnapshot assumes that one of
these xid's is committed.
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I do not think you can assume that the plan won't be used later with
some older snapshot.
So maybe we'd need to use the SerializableSnapshot created at the start
of each transaction for this check, and not the Act
On 3/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
That might work, but it doesn't seem to address the core objection:
there's no mechanism to cause the query to be replanned once the
snapshot is new enough, because no relcache inval will happen. So
most likely existing backends will keep using
On Fri, 2007-03-30 at 11:44 +0530, Pavan Deolasee wrote:
> ISTM that the run-another-transaction-afterwards idea would have same
> problem with plan invalidation. When the second transaction commits,
> the relcache invalidation event is generated. The event may get
> consumed
> by other backends,
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I do not think you can assume that the plan won't be used later with
>> some older snapshot.
> So maybe we'd need to use the SerializableSnapshot created at the start
> of each transaction for this check, and not the ActiveSnapsho
On 3/30/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
What about doing
PREPARE myplan select ... ;
outside of a transaction? Will this be execute inside a transaction?
I checked that. PREPARE runs with ActiveSnapshot set.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
Tom Lane wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
What I am suggesting is to use ActiveSnapshot (actually
Florian's idea) to decide whether the transaction that created
index was still running when we started. Isn't it the case that
some snapshot will be "active" when we plan ?
I do
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> What I am suggesting is to use ActiveSnapshot (actually
> Florian's idea) to decide whether the transaction that created
> index was still running when we started. Isn't it the case that
> some snapshot will be "active" when we plan ?
I do not think y
Tom Lane wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
How about storing the snapshot which we used during planning in
CachedPlanSource, if at least one index was seen unusable because
its CREATE INDEX transaction was seen as in-progress ?
I'm getting tired of repeating this, but: the pl
Tom Lane wrote:
>
> I'm getting tired of repeating this, but: the planner doesn't use a
> snapshot. System catalogs run on SnapshotNow.
>
I am really sorry if I sound foolish here. I am NOT suggesting
that we use "snapshot" to read system catalogs. I understand
that system catalogs run on Snapsh
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> How about storing the snapshot which we used during planning in
> CachedPlanSource, if at least one index was seen unusable because
> its CREATE INDEX transaction was seen as in-progress ?
I'm getting tired of repeating this, but: the planner doesn't
On 3/30/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
Pavan, ISTM you have misunderstood Tom slightly.
Oh, yes. Now that I re-read Tom's comment, his plan invalidation
design and code, I understand things better.
Having the index invisible to all current transactions is acceptable.
Ok.
Simon Riggs wrote:
On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will
On Thu, 2007-03-29 at 17:27 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > ISTM that the run-another-transaction-afterwards idea is the only one
> > that does everything I think we need. I really do wish we could put in a
> > wait, like CIC, but I just think it will break ex
Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
ISTM that the run-another-transaction-afterwards idea is the only one
that does everything I think we need. I really do wish we could put in a
wait, like CIC, but I just think it will break existing programs.
Actually, there's a showsto
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> ISTM that the run-another-transaction-afterwards idea is the only one
> that does everything I think we need. I really do wish we could put in a
> wait, like CIC, but I just think it will break existing programs.
Actually, there's a showstopper objection
On Thu, 2007-03-29 at 13:55 -0400, Bruce Momjian wrote:
> Pavan Deolasee wrote:
> > > Earlier we were talking about not inserting any HOT tuples until the index
> > > became valid. The goal of having an xid on the index was so we would know
> > > when
> > > we could start doing HOT updates again. T
On Thu, 2007-03-29 at 22:08 +0530, Pavan Deolasee wrote:
>
>
> On 3/29/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> It will replan at the first use of the plan after seeing the
> relcache
> inval sent by commit of the index-creating transaction. If
> you h
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> What I am proposing is to keep index unusable for existing transactions.
> The index is available for all new transactions even if there are unfinished
> existing transactions.
Ah thanks, that makes a lot more sense. Sorry for the false alarm.
--
Pavan Deolasee wrote:
> > Earlier we were talking about not inserting any HOT tuples until the index
> > became valid. The goal of having an xid on the index was so we would know
> > when
> > we could start doing HOT updates again. That seems like a much lesser cost
> > than not being able to use t
On 3/29/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
Besides, it seems if people are
happy to have indexes take a long time to build they could just do a
concurrent build.
I think we discussed this earlier. One of the down-side of CIC is that
it needs two complete heap scans. Apart from that
"Tom Lane" <[EMAIL PROTECTED]> writes:
> However, if you design something where an index becomes usable due
> to the passage of time rather than an explicit mark-valid step,
> there's gonna be a problem. I'd suggest trying to stick to the
> way CREATE INDEX CONCURRENTLY does it...
I'm a bit ske
On 3/29/07, Tom Lane <[EMAIL PROTECTED]> wrote:
It will replan at the first use of the plan after seeing the relcache
inval sent by commit of the index-creating transaction. If you have
two separate transactions to create an index and then mark it valid
later, everything's fine because there a
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Pavan Deolasee wrote:
>> Frankly I don't know this works, but are you sure that the plan will
>> be used until the end of the session ? Even if thats the case, it can
>> happen even today if we create a new index, but the existing sessions
>> will us
Pavan Deolasee wrote:
On 3/29/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Yes, but the non-index plan PREPARE generated will be used until the end
of the session, nut only until the end of the transaction.
Frankly I don't know this works, but are you sure that the plan will
be used until
On 3/29/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Yes, but the non-index plan PREPARE generated will be used until the end
of the session, nut only until the end of the transaction.
Frankly I don't know this works, but are you sure that the plan will
be used until the end of the sessio
Pavan Deolasee wrote:
In this specific context, this particular case is easy to handle because
we are only concerned about the serializable transactions started before
CREATE INDEX commits. If PREPARE can see the new index, it
implies that the CI transaction is committed. So the transaction
start
On 3/29/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> Tom, please correct me if I am wrong. But ISTM that this idea might
> work in this context. In get_relation_info(), we would check if
"xcreate"
> xid stored in pg_index for the index under consideration is seen
> co
Pavan Deolasee wrote:
On 3/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Couldn't you store the creating transaction's xid in pg_index, and
> let other transaction check that against their snapshot like they
> would for any tuple's xmin or xmax?
Wh
On Wed, 2007-03-28 at 23:42 +0530, Pavan Deolasee wrote:
>
>
> On 3/28/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> Set it at the end, not the beginning.
>
>
> At the end of what ? It does not help to set it at the end of CREATE
> INDEX because the transaction may
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Couldn't you store the creating transaction's xid in pg_index, and
let other transaction check that against their snapshot like they
would for any tuple's xmin or xmax?
What snapshot? I keep having to remind people that system cat
On 3/28/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
Set it at the end, not the beginning.
At the end of what ? It does not help to set it at the end of CREATE
INDEX because the transaction may not commit immediately. In
the meantime, many new transactions may start with
transaction id > xcr
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Couldn't you store the creating transaction's xid in pg_index, and
> let other transaction check that against their snapshot like they
> would for any tuple's xmin or xmax?
What snapshot? I keep having to remind people that system catalog
operation
On 3/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Couldn't you store the creating transaction's xid in pg_index, and
> let other transaction check that against their snapshot like they
> would for any tuple's xmin or xmax?
What snapshot? I keep ha
Simon Riggs wrote:
On Wed, 2007-03-28 at 22:24 +0530, Pavan Deolasee wrote:
Just when I thought we have nailed down CREATE INDEX, I realized
that there something more to worry. The problem is with the HOT-chains
created by our own transaction which is creating the index. We thought
it will be
On Wed, 2007-03-28 at 22:24 +0530, Pavan Deolasee wrote:
> Just when I thought we have nailed down CREATE INDEX, I realized
> that there something more to worry. The problem is with the HOT-chains
> created by our own transaction which is creating the index. We thought
> it will be enough to inde
On 3/23/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
Its slightly different for the HOT-chains created by this transaction
which
is creating the index. We should index the latest version of the row which
is not yet committed. But thats ok because when CREATE INDEX commits
this latest version
Pavan Deolasee wrote:
> > Xids are unstable and will come back to bite you after 2G transactions.
> >
> > Why not just use the "isindvalid" flag ?
> >
> >
> Who would set the flag to true ? Unless of course we are waiting in
> CREATE INDEX. But that seems to be less acceptable to me.
Agreed, and w
Hannu Krosing wrote:
> I don't think it is a good idea to store xid's anywhere but in xmin/xmax
> columns, as doing so would cause nasty xid wraparound problems.
>
> Instead you should wait, after completeing the index , for all
> concurrent transactions to end before you mark the index as "usable
Pavan Deolasee wrote:
On 3/23/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Why exactly can't a SERIALIZABLE transaction use the index it created
itself? If you add a pointer to the root of all HOT update chains where
either the HEAD is alive, or some tuple is visible to the transaction
crea
On 3/23/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Why exactly can't a SERIALIZABLE transaction use the index it created
itself? If you add a pointer to the root of all HOT update chains where
either the HEAD is alive, or some tuple is visible to the transaction
creating the index, shouldn
Pavan Deolasee wrote:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data, but I don't think anybody is going to
complain about that restriction. Anyone?
Oh, I did not se
On 3/23/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> My argument is that its enough to index only the LIVE tuple which
> is at the end of the chain if we don't use the new index for queries
> in transactions which were started before CREATE INDEX.
You mean, which were started before CREAT
Ühel kenal päeval, K, 2007-03-21 kell 14:06, kirjutas Merlin Moncure:
> On 3/21/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
> > Pavan Deolasee wrote:
> > > On 3/21/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > >>
> > >> On 3/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> > >> > It seems
Ühel kenal päeval, N, 2007-03-22 kell 07:09, kirjutas Andrew Dunstan:
> Pavan Deolasee wrote:
> > What I am hearing from many users is that its probably not such
> > a nice thing to put such restriction. Thats fair. It really helps to think
> > about a solution once you know what is acceptable and
Ühel kenal päeval, N, 2007-03-22 kell 23:30, kirjutas Pavan Deolasee:
>
>
> On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > When CREATE INDEX starts, it acquires ShareLock on the
> table.
> > At this point we may h
On 3/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
The ShareLock taken by CREATE INDEX guarantees all transactions that
wrote data to the table have completed and that no new data can be added
until after the index build commits. So the end of the chain is visible
to CREATE INDEX and won't cha
Simon Riggs wrote:
On Thu, 2007-03-22 at 16:16 -0400, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
There is a slight hole in that SERIALIZABLE transactions won't be able
to use any indexes they build during their transaction, since they may
need to be able to see prior data
On Thu, 2007-03-22 at 16:16 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > There is a slight hole in that SERIALIZABLE transactions won't be able
> > to use any indexes they build during their transaction, since they may
> > need to be able to see prior data, but I don't thi
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> There is a slight hole in that SERIALIZABLE transactions won't be able
> to use any indexes they build during their transaction, since they may
> need to be able to see prior data, but I don't think anybody is going to
> complain about that restriction. A
On Thu, 2007-03-22 at 22:11 +0530, Pavan Deolasee wrote:
> With this background, I propose to index ONLY the head of the
> HOT-chain. The TID of the root tuple is used instead of the actual
> TID of the tuple being indexed. This index will not be available to
> the transactions which are started b
Pavan Deolasee wrote:
> My argument is that its enough to index only the LIVE tuple which
> is at the end of the chain if we don't use the new index for queries
> in transactions which were started before CREATE INDEX. I am
> proposing to do that by storing an xid in the pg_index row. A
> special
On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> When CREATE INDEX starts, it acquires ShareLock on the table.
> At this point we may have one or more HOT-update chains in the
> table. Tuples in this chain may be visible to one or more running
> tran
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> When CREATE INDEX starts, it acquires ShareLock on the table.
> At this point we may have one or more HOT-update chains in the
> table. Tuples in this chain may be visible to one or more running
> transactions. The fact that we have ShareLock on the ta
On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
A different idea is to flag the _index_ as using HOT for the table or
not, using a boolean in pg_index. The idea is that when a new index is
created, it has its HOT boolean set to false and indexes all tuples and
ignores HOT chains. Then d
On 3/22/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
On 3/22/07, Csaba Nagy <[EMAIL PROTECTED]> wrote:
> > speaking with pavan off list he seems to think that only 'create
> > index' is outside transaction, not the other ddl flavors of it because
> > they are generally acquiring a excl lock. so
Pavan Deolasee wrote:
What I am hearing from many users is that its probably not such
a nice thing to put such restriction. Thats fair. It really helps to think
about a solution once you know what is acceptable and what is not.
That's likely to be the reaction for almost any restriction you ca
On 3/22/07, Csaba Nagy <[EMAIL PROTECTED]> wrote:
> speaking with pavan off list he seems to think that only 'create
> index' is outside transaction, not the other ddl flavors of it because
> they are generally acquiring a excl lock. so, in that sense it is
> possibly acceptable to me although
> speaking with pavan off list he seems to think that only 'create
> index' is outside transaction, not the other ddl flavors of it because
> they are generally acquiring a excl lock. so, in that sense it is
> possibly acceptable to me although still a pretty tough pill to
> swallow (thinking, guc
Bruce Momjian wrote:
Anyway, perhaps we can leave the bitmap scan part to someone more
familiar with that part of the code, like Tom.
Yeah. We all know he doesn't have enough to do ...
cheers
andrew
---(end of broadcast)---
TIP 5: don't
Bruce Momjian wrote:
> > You don't need to scan the whole page like in the lossy bitmap mode,
> > just all the tuples in the HOT-chain.
> >
> > You need to somehow pass the information that multiple indexes have been
> > used in the bitmap scan to the bitmap heapscan node, so that it knows
> >
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >> Bruce Momjian wrote:
> Also, I am wondering whether the information that which index is used to
> fetch a tuple is always available. I haven't checked, but do we have that
> information in lossy bitmap hea
Bruce Momjian wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Also, I am wondering whether the information that which index is used to
fetch a tuple is always available. I haven't checked, but do we have that
information in lossy bitmap heapscan ?
Oh, that is an interesting problem because an
On Wed, 2007-03-21 at 13:29 -0400, Bruce Momjian wrote:
> Pavan Deolasee wrote:
> > On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > I am worried that will require CREATE INDEX to wait for a long time.
> >
> >
> >
> > Not unless there are long running transactions. We
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > > Also, I am wondering whether the information that which index is used to
> > > fetch a tuple is always available. I haven't checked, but do we have that
> > > information in lossy bitmap heapscan ?
> >
> > Oh, that is an interesting problem because
Bruce Momjian wrote:
> > Also, I am wondering whether the information that which index is used to
> > fetch a tuple is always available. I haven't checked, but do we have that
> > information in lossy bitmap heapscan ?
>
> Oh, that is an interesting problem because an index might have one index
>
Pavan Deolasee wrote:
> On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> >
> > Effectively, my idea is not to chill/break the HOT chains during index
> > creation, but rather to abandon them and wait for VACUUM to clean them
> > up.
> >
> > My idea is much closer to the idea of a bit per
On 3/21/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> On 3/21/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
>>
>> On 3/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
>> > It seems much simpler to me do something like this. But important
>> > question is whether the res
Pavan Deolasee wrote:
On 3/21/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 3/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> It seems much simpler to me do something like this. But important
> question is whether the restriction that CREATE INDEX can not
> be run in a transaction block i
On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Effectively, my idea is not to chill/break the HOT chains during index
creation, but rather to abandon them and wait for VACUUM to clean them
up.
My idea is much closer to the idea of a bit per index on every tuple,
except the tuple xmax and
On 3/21/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 3/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> It seems much simpler to me do something like this. But important
> question is whether the restriction that CREATE INDEX can not
> be run in a transaction block is acceptable ?
yikes -
On 3/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
It seems much simpler to me do something like this. But important
question is whether the restriction that CREATE INDEX can not
be run in a transaction block is acceptable ?
yikes -- this is huge, huge price to pay, IMHO. Think about DDL th
Effectively, my idea is not to chill/break the HOT chains during index
creation, but rather to abandon them and wait for VACUUM to clean them
up.
My idea is much closer to the idea of a bit per index on every tuple,
except the tuple xmax and pg_index xid replace them.
---
Pavan Deolasee wrote:
> On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > I am worried that will require CREATE INDEX to wait for a long time.
>
>
>
> Not unless there are long running transactions. We are not waiting
> for the lock, but only for the current transactions to fi
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > As stated in later email, I think we should focus on the xid idea
> > because it is more flexible.
>
> Sorry if I was unclear. I agree, my comment and questions are all predicated
> on the assumption that we would go with xi
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> As stated in later email, I think we should focus on the xid idea
> because it is more flexible.
Sorry if I was unclear. I agree, my comment and questions are all predicated
on the assumption that we would go with xids.
> --
On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I am worried that will require CREATE INDEX to wait for a long time.
Not unless there are long running transactions. We are not waiting
for the lock, but only for the current transactions to finish.
Is the pg_index xid idea too compl
Pavan Deolasee wrote:
> On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Bruce Momjian wrote:
> > >
> > > I have read the HOT discussion and wanted to give my input. The major
> > > issue is that CREATE INDEX might require a HOT chain to be split apart
> > > if one of the new indexed c
As stated in later email, I think we should focus on the xid idea
because it is more flexible.
---
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > We also add a boolean to pg_class to indicate no
Ah, sounds like you have the idea clearly now. Great.
---
Heikki Linnakangas wrote:
> Sorry, I was a bit too quick to respond. I didn't understand at first
> how this differs from Pavan's/Simon's proposals.
>
> Let me ans
Simon Riggs wrote:
> On Wed, 2007-03-21 at 10:47 -0400, Bruce Momjian wrote:
>
> > A different idea is to flag the _index_ as using HOT for the table or
> > not, using a boolean in pg_index. The idea is that when a new index is
> > created, it has its HOT boolean set to false and indexes all tupl
On 3/21/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Bruce Momjian wrote:
>
> I have read the HOT discussion and wanted to give my input. The major
> issue is that CREATE INDEX might require a HOT chain to be split apart
> if one of the new indexed columns changed in the HOT chain.
To expand a
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > A different idea is to flag the _index_ as using HOT for the table or
> > not, using a boolean in pg_index. The idea is that when a new index is
> > created, it has its HOT boolean set to false and indexes all tuples and
> > ignores HOT chains.
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> We also add a boolean to pg_class to indicate no new HOT chains should be
> created and set that to false once the new index is created.
Since we have all the index info in the relcache we could just skim through
all the indexes when we build the rel
Sorry, I was a bit too quick to respond. I didn't understand at first
how this differs from Pavan's/Simon's proposals.
Let me answer my own questions.
Heikki Linnakangas wrote:
Bruce Momjian wrote:
A different idea is to flag the _index_ as using HOT for the table or
not, using a boolean in p
On Wed, 2007-03-21 at 10:47 -0400, Bruce Momjian wrote:
> A different idea is to flag the _index_ as using HOT for the table or
> not, using a boolean in pg_index. The idea is that when a new index is
> created, it has its HOT boolean set to false and indexes all tuples and
> ignores HOT chains.
Bruce Momjian wrote:
A different idea is to flag the _index_ as using HOT for the table or
not, using a boolean in pg_index. The idea is that when a new index is
created, it has its HOT boolean set to false and indexes all tuples and
ignores HOT chains. Then doing lookups using that index, the
Bruce Momjian wrote:
>
> I have read the HOT discussion and wanted to give my input. The major
> issue is that CREATE INDEX might require a HOT chain to be split apart
> if one of the new indexed columns changed in the HOT chain.
To expand a little more, the problem is that when you split those
I have read the HOT discussion and wanted to give my input. The major
issue is that CREATE INDEX might require a HOT chain to be split apart
if one of the new indexed columns changed in the HOT chain.
As for the outline below, there is no way we are going to add new ALTER
TABLE and CHILL command
94 matches
Mail list logo
