I really like the CREATE INDEX CONCURRENTLY suggestion that I've seem in this
thread. That seems like a good alternative to ONLINE and is very easy to
understand.
Regards,
Paul
--
View this message in context:
Quoting Greg Stark [EMAIL PROTECTED]:
Tom Lane [EMAIL PROTECTED] writes:
I'm fairly dissatisfied with the naming of Greg Stark's proposed new
feature for creating indexes without blocking writers of the table.
To my mind, ONLINE just doesn't convey any useful information ---
the existing
I understand the negative implications with calling it ONLINE with regards
to the index rebuild but I believe that would follow what the industry and
professionals understand. Oracle denotes this concept as ONLINE and
microsoft with it's new SQL Server 2005 markets the ability to do ONLINE
Ühel kenal päeval, K, 2006-07-26 kell 06:40, kirjutas Gregory S Stark:
The DB2 handbook says Tables can now be reorganized online with almost full
acess to the table allowed but their syntax does not use the word online.
Does this reorganizing refer to what we do with CLUSTER ?
I'd really love
Peter Eisentraut [EMAIL PROTECTED] writes:
Greg Stark wrote:
One thing to think about, what will the command to execute stored
procedures look like? Those will also need to be called from outside
a transaction.
Huh? Only if you invent your own stored-procedure theory or have a
Paul Silveira [EMAIL PROTECTED] writes:
If I didn't know anything about PostgreSQL and read a manual about it's
indexing capabilities and read that it had ONLINE reindexing, the first
thing that I would think about was the ability to rebuild my indexes without
causing any blocking or writers
Gregory Start wrote:
Fwiw a few data points:
MSSQL uses (WITH ONLINE=ON) much like we and Oracle use ONLINE tacked
on to the
end of the create index command.
Where did you find this? I thought my MSDN-foo was pretty good, and I
didn't find this when searched a couple days ago.
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, K, 2006-07-26 kell 06:40, kirjutas Gregory S Stark:
The DB2 handbook says Tables can now be reorganized online with almost full
acess to the table allowed but their syntax does not use the word online.
Does this reorganizing
Yeah, your probably right. :)
On 7/26/06, Tom Lane [EMAIL PROTECTED] wrote:
Paul Silveira [EMAIL PROTECTED] writes: If I didn't know anything about PostgreSQL and read a manual about it's
indexing capabilities and read that it had ONLINE reindexing, the first thing that I would think about was
Ühel kenal päeval, K, 2006-07-26 kell 13:23, kirjutas Gregory Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
Ühel kenal päeval, K, 2006-07-26 kell 06:40, kirjutas Gregory S Stark:
The DB2 handbook says Tables can now be reorganized online with almost
full
acess to the table
Am Dienstag, 25. Juli 2006 06:55 schrieb Bruce Momjian:
Or maybe CREATE INDEX x ON tab NOLOCK Having the NOLOCK
associated with the table name makes sense.
Semantically, NOLOCK (or whatever word) seems most closely associated with
CREATE INDEX, so having it as third word would make sense,
Peter Eisentraut wrote:
Am Dienstag, 25. Juli 2006 06:55 schrieb Bruce Momjian:
Or maybe CREATE INDEX x ON tab NOLOCK Having the NOLOCK
associated with the table name makes sense.
Semantically, NOLOCK (or whatever word) seems most closely associated with
CREATE INDEX, so having it
Semantically, NOLOCK (or whatever word) seems most closely associated with
CREATE INDEX, so having it as third word would make sense, and it would be
quite easy to parse for psql.
Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
In this case CREATE INDEX
Csaba Nagy [EMAIL PROTECTED] writes:
Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
In this case CREATE INDEX CONCURRENTLY ... sounds better to me, although
the whole feature sounds nice any way you will finally call it ;-)
That reads well to me too. We'd need to
Ühel kenal päeval, T, 2006-07-25 kell 11:26, kirjutas Tom Lane:
Csaba Nagy [EMAIL PROTECTED] writes:
Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
In this case CREATE INDEX CONCURRENTLY ... sounds better to me, although
the whole feature sounds nice any way
Tom Lane wrote:
psql could actually tell these apart if it worked just a bit harder.
CLUSTER with no arguments is the one case, CLUSTER with
anything after it is the other. Not sure why we couldn't be
bothered to get that right in psql the first time :-(.
Should this go on the to-do
On 7/25/06, Tom Lane [EMAIL PROTECTED] wrote:
Csaba Nagy [EMAIL PROTECTED] writes:
Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
In this case CREATE INDEX CONCURRENTLY ... sounds better to me, although
the whole feature sounds nice any way you will finally call
Marko Kreen [EMAIL PROTECTED] writes:
Is there a chance that the locking variant will be replaced by
non-locking variant,
No, I don't think so. Given that the concurrent form is much slower
(extra table scan) and can't be wrapped into a transaction block,
it'll always be a special option.
I'm fairly dissatisfied with the naming of Greg Stark's proposed new
feature for creating indexes without blocking writers of the table.
To my mind, ONLINE just doesn't convey any useful information ---
the existing CREATE INDEX functionality could already be said to be
online, in the sense that
SHARED CREATE INDEX
Comments?
CREATE [UNIQUE] INDEX foo [WITH NOLOCK] ON ...
--
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Sorry, hit send too quickly.
NOLOCK is kinda like NOWAIT, except implies that the command will not
take a strong lock instead of stating that it will not wait for one.
On Mon, 2006-07-24 at 11:20 -0400, Rod Taylor wrote:
SHARED CREATE INDEX
Comments?
CREATE [UNIQUE] INDEX foo
Am Montag, 24. Juli 2006 17:13 schrieb Tom Lane:
To my mind, ONLINE just doesn't convey any useful information ---
the existing CREATE INDEX functionality could already be said to be
online, in the sense that you don't have to take down the database
to do it. I thought about SHARED but
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 24. Juli 2006 17:13 schrieb Tom Lane:
I'm tempted to put the new keyword at the very front:
SHARED CREATE INDEX
which would probably mean that we'd have to document it as if it were a
completely separate command from CREATE INDEX,
Tom Lane [EMAIL PROTECTED] writes:
I'm fairly dissatisfied with the naming of Greg Stark's proposed new
feature for creating indexes without blocking writers of the table.
To my mind, ONLINE just doesn't convey any useful information ---
the existing CREATE INDEX functionality could already
Greg Stark asked:
I know Oracle calls this online index builds. In fact it
works similarly
with a single keyword online tacked on near the end of the
create index
statement.
Anyone know what MSSQL or DB2 call it?
I have to live with MSSQL at work, and I didn't remember anything like
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
I'm also wondering about where in the command the keyword should go.
As submitted it's
[ WITH ( replaceable
class=PARAMETERstorage_parameter/replaceable = replaceable
class=PARAMETERvalue/replaceable [, ... ] ) ]
Greg Stark wrote:
One thing to think about, what will the command to execute stored
procedures look like? Those will also need to be called from outside
a transaction.
Huh? Only if you invent your own stored-procedure theory or have a
hitherto unknown interpretation of the SQL standard.
--
Peter Eisentraut wrote:
Greg Stark wrote:
One thing to think about, what will the command to execute stored
procedures look like? Those will also need to be called from outside
a transaction.
Huh? Only if you invent your own stored-procedure theory or have a
hitherto unknown
Rod Taylor wrote:
Sorry, hit send too quickly.
NOLOCK is kinda like NOWAIT, except implies that the command will not
take a strong lock instead of stating that it will not wait for one.
On Mon, 2006-07-24 at 11:20 -0400, Rod Taylor wrote:
SHARED CREATE INDEX
I like NOLOCK
Bruce Momjian wrote:
Rod Taylor wrote:
Sorry, hit send too quickly.
NOLOCK is kinda like NOWAIT, except implies that the command will not
take a strong lock instead of stating that it will not wait for one.
On Mon, 2006-07-24 at 11:20 -0400, Rod Taylor wrote:
SHARED
Bruce Momjian wrote:
Anyway, if you want psql to easily identify it, just return NOLOCK as
part of the command string returned:
test= create index i on test(x);
CREATE INDEX NOLOCK
Oh, psql needs to know before the command is sent? How do we handle it
now with CLUSTER?
We
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Oh, psql needs to know before the command is sent? How do we handle it
now with CLUSTER?
We don't, which is exactly the problem. If I'm not mistaken, currently
psql in autocommit off mode, CLUSTER doesn't start a transaction
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
Oh, psql needs to know before the command is sent? How do we handle it
now with CLUSTER?
We don't, which is exactly the problem. If I'm not mistaken, currently
psql in autocommit off mode, CLUSTER doesn't
Bruce Momjian [EMAIL PROTECTED] writes:
OK, how about CREATE INDEX x NOLOCK ON tab ... Please don't use it as
the first word. I am afraid we would regret that.
Or maybe CREATE INDEX x ON tab NOLOCK Having the NOLOCK
associated with the table name makes sense.
psql would be a lot
34 matches
Mail list logo
