Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
What if we only applied
HOT to primary-key indexes, so that there was certainly not more than
one index per table that the property applies to?
The main objective of HOT is to enable retail vacuum of HOT-updated tuples.
Doing
Pavan Deolasee wrote:
What is the safest way to access/modify the pg_class attribute
and still avoid any race conditions with the other backends ?
A specific example is: To solve the CREATE INDEX problem with
HOT, I am thinking of adding (along with other things) a pg_class
boolean
Pavan Deolasee [EMAIL PROTECTED] writes:
My understanding is that the backend which sets this attribute
must first acquire a lock on the heap relation of sufficient
strength so as to ensure that there are no concurrent UPDATErs,
update the pg_class row and then release the lock on the
Tom Lane wrote:
In what context are you proposing to do that, and won't this
high-strength lock in itself lead to deadlocks?
The whole thing sounds exceedingly ugly anyway --- for example
what happens if the backend doing the CREATE INDEX fails and
is therefore unable to clear the flag
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(. I thought from the beginning
that CREATE INDEX might be a showstopper for the whole HOT concept,
and it's starting to look like that's the case.
I think what we need to get
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(. I thought from the beginning
that CREATE INDEX might be a showstopper for the whole HOT concept,
and it's starting to look like that's the case.
I
Tom Lane wrote:
What if we only applied
HOT to primary-key indexes, so that there was certainly not more than
one index per table that the property applies to?
The main objective of HOT is to enable retail vacuum of HOT-updated
tuples. Doing the above would make it useless for that purpose,
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(.
Yes, it looks a bit complex. But IMHO we can get around that.
Do you have any ideas in mind about doing that ?
I thought from the beginning
that CREATE
On Fri, 2007-03-16 at 21:56 +0530, Pavan Deolasee wrote:
Any thoughts on the overall approach ? Any suggestions to
simplify things or any alternate designs ?
Well your design is very different from what we discussed, so I think I
should post my proposed design alongside this, for further
Joshua D. Drake [EMAIL PROTECTED] writes:
Just to throw my two bits in here :). If we do that, how does that
effect the idea that most people in the web world use (id serial primary
key), even though that is not what they are searching on?
affect. But I think you're right that generally
Heikki Linnakangas wrote:
Tom Lane wrote:
What if we only applied
HOT to primary-key indexes, so that there was certainly not more than
one index per table that the property applies to?
The main objective of HOT is to enable retail vacuum of HOT-updated
tuples. Doing the above would make
On Fri, 2007-03-16 at 12:40 -0400, Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
Any thoughts on the overall approach ?
Fragile and full of race conditions :-(. I thought from the beginning
that CREATE INDEX might be a showstopper for the whole HOT concept,
and it's starting to
Gregory Stark wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Just to throw my two bits in here :). If we do that, how does that
effect the idea that most people in the web world use (id serial primary
key), even though that is not what they are searching on?
affect. But I think you're
Simon Riggs wrote:
What if we only applied
HOT to primary-key indexes, so that there was certainly not more than
one index per table that the property applies to?
On its own, I don't think this is a sufficiently wide use-case.
Perhaps we should do this PLUS make HOT-semantics optional
On Fri, 2007-03-16 at 16:59 -0400, Alvaro Herrera wrote:
Here's is a very simple, low-tech idea. How about checking whether the
new index requires chilling tuples; if it does, then elog(ERROR) until
all the indexes have been manually chilled, which would be done with an
ALTER INDEX ... CHILL
15 matches
Mail list logo
