Re: [HACKERS] SET WITHOUT CLUSTER patch
Christopher Kings-Lynne wrote: Now, I have to change that relation_expr to qualified_name. However, this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET WITHOUT OIDS.) Well, seems like what you have to do is leave it as relation_expr as far as bison is concerned, but test in the C-code action and error out if * was specified. (Accepting ONLY seems alright to me.) Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse. Should I make it do that, even though the CLUSTER ON form cannot? I just thought about this. CLUSTER is more of a storage-level specification, rather than a logical one. Seems it is OK that WITOUTH CLUSTER not recurse into inherited tables, especially since the CLUSTER command does not. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] SET WITHOUT CLUSTER patch
Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse. Should I make it do that, even though the CLUSTER ON form cannot? I just thought about this. CLUSTER is more of a storage-level specification, rather than a logical one. Seems it is OK that WITOUTH CLUSTER not recurse into inherited tables, especially since the CLUSTER command does not. The patch I submitted earlier already does do recursion - I don't see why it shouldn't really. It's better than failing saying that legal grammar is in fact illegal :) Chris ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SET WITHOUT CLUSTER patch
Christopher Kings-Lynne wrote: Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse. Should I make it do that, even though the CLUSTER ON form cannot? I just thought about this. CLUSTER is more of a storage-level specification, rather than a logical one. Seems it is OK that WITOUTH CLUSTER not recurse into inherited tables, especially since the CLUSTER command does not. The patch I submitted earlier already does do recursion - I don't see why it shouldn't really. It's better than failing saying that legal grammar is in fact illegal :) Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I think, and throwing an error seems fine to me, even if it isn't the same wording as a syntax error. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] SET WITHOUT CLUSTER patch
Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I think, and throwing an error seems fine to me, even if it isn't the same wording as a syntax error. Well, maybe - up to you. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] SET WITHOUT CLUSTER patch
Christopher Kings-Lynne wrote: Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I think, and throwing an error seems fine to me, even if it isn't the same wording as a syntax error. Well, maybe - up to you. Well, if we don't recurse on creation, does it make sense to recurse on destruction? Seems it might surpise people. Do we have that asymetry in any other area? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SET WITHOUT CLUSTER patch
On Sun, May 02, 2004 at 06:23:30PM -0400, Bruce Momjian wrote: Christopher Kings-Lynne wrote: Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I think, and throwing an error seems fine to me, even if it isn't the same wording as a syntax error. Well, maybe - up to you. Well, if we don't recurse on creation, does it make sense to recurse on destruction? Seems it might surpise people. Do we have that asymetry in any other area? I'm not sure if it's assymetric. You can't recursively set the cluster bit, because child tables may not have an equally named index. However when you are unsetting the bit it doesn't matter how is the index named. I'm not sure what side does this argument favor. I'd say ALTER TABLE/WITHOUT CLUSTER shouldn't recurse but I don't feel strongly about it. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Everybody understands Mickey Mouse. Few understand Hermann Hesse. Hardly anybody understands Einstein. And nobody understands Emperor Norton. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] SET WITHOUT CLUSTER patch
Alvaro Herrera wrote: On Sun, May 02, 2004 at 06:23:30PM -0400, Bruce Momjian wrote: Christopher Kings-Lynne wrote: Uh, if the CLUSTER doesn't recurse, the WITHOUT shouldn't either, I think, and throwing an error seems fine to me, even if it isn't the same wording as a syntax error. Well, maybe - up to you. Well, if we don't recurse on creation, does it make sense to recurse on destruction? Seems it might surpise people. Do we have that asymetry in any other area? I'm not sure if it's assymetric. You can't recursively set the cluster bit, because child tables may not have an equally named index. However when you are unsetting the bit it doesn't matter how is the index named. Right, we can recurse on WITHOUT and not using WITH, but would people expect WITHOUT to recurse? If we allowed indexes to span tables, it would be nice for both to recurse, but because we don't, I think neither should. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SET WITHOUT CLUSTER patch
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Well, seems like what you have to do is leave it as relation_expr as far as bison is concerned, but test in the C-code action and error out if * was specified. (Accepting ONLY seems alright to me.) Actually, it occurs to me that the SET WITHOUT CLUSTER form CAN recurse. Should I make it do that, even though the CLUSTER ON form cannot? Seems like more work than it's really worth ... but if you wanna ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] SET WITHOUT CLUSTER patch
Hi,
I have done a patch for turning off clustering on a table entirely.
Unforunately, of the three syntaxes I can think of, all cause
shift/reduce errors:
SET WITHOUT CLUSTER;
DROP CLUSTER
CLUSTER ON NONE;
This is the new grammar that I added:
/* ALTER TABLE name SET WITHOUT CLUSTER */
| ALTER TABLE relation_expr SET WITHOUT CLUSTER
{
AlterTableStmt *n = makeNode(AlterTableStmt);
n-subtype = 'L';
n-relation = $3;
n-name = NULL;
$$ = (Node *)n;
}
Now, I have to change that relation_expr to qualified_name. However,
this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET
WITHOUT OIDS.)
Even changing the syntax to qualified_name DROP CLUSTER doesn't work
due to the existence of relation_expr DROP
What's the solution? I can't figure it out...
Chris
Index: doc/src/sgml/ref/alter_table.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ref/alter_table.sgml,v
retrieving revision 1.66
diff -c -r1.66 alter_table.sgml
*** doc/src/sgml/ref/alter_table.sgml 9 Mar 2004 16:57:47 - 1.66
--- doc/src/sgml/ref/alter_table.sgml 18 Mar 2004 03:51:41 -
***
*** 47,52
--- 47,54
OWNER TO replaceable class=PARAMETERnew_owner/replaceable
ALTER TABLE replaceable class=PARAMETERname/replaceable
CLUSTER ON replaceable class=PARAMETERindex_name/replaceable
+ ALTER TABLE replaceable class=PARAMETERname/replaceable
+ SET WITHOUT CLUSTER
/synopsis
/refsynopsisdiv
***
*** 219,224
--- 221,235
/listitem
/varlistentry
+varlistentry
+ termliteralSET WITHOUT CLUSTER/literal/term
+ listitem
+ para
+ This form disables future xref linkend=SQL-CLUSTER
endterm=sql-cluster-title on a table.
+ /para
+ /listitem
+/varlistentry
+
/variablelist
/para
Index: src/backend/commands/tablecmds.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/tablecmds.c,v
retrieving revision 1.100
diff -c -r1.100 tablecmds.c
*** src/backend/commands/tablecmds.c13 Mar 2004 22:09:13 - 1.100
--- src/backend/commands/tablecmds.c18 Mar 2004 03:51:42 -
***
*** 3970,3999
rel = heap_open(relOid, AccessExclusiveLock);
- indexOid = get_relname_relid(indexName, rel-rd_rel-relnamespace);
-
- if (!OidIsValid(indexOid))
- ereport(ERROR,
- (errcode(ERRCODE_UNDEFINED_OBJECT),
-errmsg(index \%s\ for table \%s\ does not exist,
- indexName,
NameStr(rel-rd_rel-relname;
-
- indexTuple = SearchSysCache(INDEXRELID,
-
ObjectIdGetDatum(indexOid),
- 0, 0, 0);
- if (!HeapTupleIsValid(indexTuple))
- elog(ERROR, cache lookup failed for index %u, indexOid);
- indexForm = (Form_pg_index) GETSTRUCT(indexTuple);
-
/*
!* If this is the same index the relation was previously clustered on,
!* no need to do anything.
*/
! if (indexForm-indisclustered)
! {
! ReleaseSysCache(indexTuple);
! heap_close(rel, NoLock);
! return;
}
pg_index = heap_openr(IndexRelationName, RowExclusiveLock);
--- 3970,4010
rel = heap_open(relOid, AccessExclusiveLock);
/*
!* We only fetch the index if indexName is not null. A null index
! * name indicates that we're removing all clustering on this table.
*/
! if (indexName != NULL) {
! indexOid = get_relname_relid(indexName, rel-rd_rel-relnamespace);
!
! if (!OidIsValid(indexOid))
! ereport(ERROR,
! (errcode(ERRCODE_UNDEFINED_OBJECT),
!errmsg(index \%s\ for table \%s\ does
not exist,
! indexName,
NameStr(rel-rd_rel-relname;
!
! indexTuple = SearchSysCache(INDEXRELID,
!
ObjectIdGetDatum(indexOid),
! 0, 0, 0);
! if (!HeapTupleIsValid(indexTuple))
! elog(ERROR, cache lookup failed for index %u, indexOid);
! indexForm = (Form_pg_index) GETSTRUCT(indexTuple);
!
! /*
!* If this is the same index the relation was previously clustered on,
!* no need to do anything.
!*/
! if
Re: [HACKERS] SET WITHOUT CLUSTER patch
Christopher Kings-Lynne [EMAIL PROTECTED] writes: This is the new grammar that I added: | ALTER TABLE relation_expr SET WITHOUT CLUSTER Now, I have to change that relation_expr to qualified_name. However, this causes shift/reduce errors. (Due to ALTER TABLE relation_expr SET WITHOUT OIDS.) Well, seems like what you have to do is leave it as relation_expr as far as bison is concerned, but test in the C-code action and error out if * was specified. (Accepting ONLY seems alright to me.) You could possibly find a solution at the grammar level but it'd probably be a much worse kluge ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
