Thread: indisclustered and clusterdb
Hello, I attach a little patch to make CLUSTER set and reset the indisclustered bit on the indexes. I also attach clusterdb and clusterdb.sgml; both of them are blatant rips of vacuumdb and vacuumdb.sgml, but get the job done. Please review them, as I'm probably making a lot of mistakes with SGML and I can't compile it here. vacuumdb itself is not very comfortable to use when the databases have passwords, because it has to connect once for each table (I can probably make it connect only once for each database; should I?). Because of this I added a mention of PGPASSWORDFILE in the documentation, but I don't know if that is the correct place for that. If no objections to the indisclustered thing, please apply it. -- Alvaro Herrera (<alvherre[a]atentus.com>) "No deja de ser humillante para una persona de ingenio saber que no hay tonto que no le pueda enseñar algo." (Jean B. Say)
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Alvaro Herrera wrote:
> Hello,
>
> I attach a little patch to make CLUSTER set and reset the indisclustered
> bit on the indexes.
>
> I also attach clusterdb and clusterdb.sgml; both of them are blatant
> rips of vacuumdb and vacuumdb.sgml, but get the job done. Please review
> them, as I'm probably making a lot of mistakes with SGML and I can't
> compile it here.
>
> vacuumdb itself is not very comfortable to use when the databases have
> passwords, because it has to connect once for each table (I can probably
> make it connect only once for each database; should I?). Because of
> this I added a mention of PGPASSWORDFILE in the documentation, but I
> don't know if that is the correct place for that.
>
> If no objections to the indisclustered thing, please apply it.
>
> --
> Alvaro Herrera (<alvherre[a]atentus.com>)
> "No deja de ser humillante para una persona de ingenio saber
> que no hay tonto que no le pueda ense?ar algo." (Jean B. Say)
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Patch applied. Thanks. I made changes to the Makefile and the SGML build system to handle your new files. I will see how the SGML build does and we can adjust it. I will add the PGPASSWORDFILE mention to vacuumdb and pg_dumpall. --------------------------------------------------------------------------- Alvaro Herrera wrote: > Hello, > > I attach a little patch to make CLUSTER set and reset the indisclustered > bit on the indexes. > > I also attach clusterdb and clusterdb.sgml; both of them are blatant > rips of vacuumdb and vacuumdb.sgml, but get the job done. Please review > them, as I'm probably making a lot of mistakes with SGML and I can't > compile it here. > > vacuumdb itself is not very comfortable to use when the databases have > passwords, because it has to connect once for each table (I can probably > make it connect only once for each database; should I?). Because of > this I added a mention of PGPASSWORDFILE in the documentation, but I > don't know if that is the correct place for that. > > If no objections to the indisclustered thing, please apply it. > > -- > Alvaro Herrera (<alvherre[a]atentus.com>) > "No deja de ser humillante para una persona de ingenio saber > que no hay tonto que no le pueda ense?ar algo." (Jean B. Say) Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
BTW, clusterdb is not schema-aware and will surely fail in any database
where more than one schema is in use, because it doesn't trouble to
schema-qualify table names.
regards, tom lane
Added to open items. I wonder if vacuumdb and reindexdb are OK? --------------------------------------------------------------------------- Tom Lane wrote: > BTW, clusterdb is not schema-aware and will surely fail in any database > where more than one schema is in use, because it doesn't trouble to > schema-qualify table names. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Added to open items. I wonder if vacuumdb and reindexdb are OK?
Wouldn't count on it. All those scripts need to be looked over.
I just posted a first cut at a "things to look for" list.
regards, tom lane
Tom Lane dijo: > BTW, clusterdb is not schema-aware and will surely fail in any database > where more than one schema is in use, because it doesn't trouble to > schema-qualify table names. Doh. I will look into it. -- Alvaro Herrera (<alvherre[a]atentus.com>) "El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte" (Ijon Tichy en Viajes, Stanislaw Lem)
En Mon, 02 Sep 2002 21:14:01 -0400 Tom Lane <tgl@sss.pgh.pa.us> escribió: > BTW, clusterdb is not schema-aware and will surely fail in any database > where more than one schema is in use, because it doesn't trouble to > schema-qualify table names. Ok, the following patch should solve this concern. It also tries to connect as little times as possible (the previous one would connect one time per table plus one per database; this one connects two times per database). It's ugly and has the same concurrency problems that arose for the original CLUSTER ALL patch, but I don't think there's a clean way to solve them in a shell script. Maybe an indication should be put in clusterdb.sgml that it should run separate from standard CLUSTER operations or from other runs of clusterdb? Sorry this took so long. -- Alvaro Herrera (<alvherre[a]atentus.com>) "There was no reply" (Kernel Traffic)
Attachment
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Alvaro Herrera wrote:
> En Mon, 02 Sep 2002 21:14:01 -0400
> Tom Lane <tgl@sss.pgh.pa.us> escribi?:
>
> > BTW, clusterdb is not schema-aware and will surely fail in any database
> > where more than one schema is in use, because it doesn't trouble to
> > schema-qualify table names.
>
> Ok, the following patch should solve this concern. It also tries to
> connect as little times as possible (the previous one would connect one
> time per table plus one per database; this one connects two times per
> database).
>
> It's ugly and has the same concurrency problems that arose for the
> original CLUSTER ALL patch, but I don't think there's a clean way to
> solve them in a shell script. Maybe an indication should be put in
> clusterdb.sgml that it should run separate from standard CLUSTER
> operations or from other runs of clusterdb?
>
> Sorry this took so long.
>
> --
> Alvaro Herrera (<alvherre[a]atentus.com>)
> "There was no reply" (Kernel Traffic)
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Patch applied. Thanks.
We will deal with this TODO in 7.4:
o Allow CLUSTER to cluster all tables, remove clusterdb
---------------------------------------------------------------------------
Alvaro Herrera wrote:
> En Mon, 02 Sep 2002 21:14:01 -0400
> Tom Lane <tgl@sss.pgh.pa.us> escribi?:
>
> > BTW, clusterdb is not schema-aware and will surely fail in any database
> > where more than one schema is in use, because it doesn't trouble to
> > schema-qualify table names.
>
> Ok, the following patch should solve this concern. It also tries to
> connect as little times as possible (the previous one would connect one
> time per table plus one per database; this one connects two times per
> database).
>
> It's ugly and has the same concurrency problems that arose for the
> original CLUSTER ALL patch, but I don't think there's a clean way to
> solve them in a shell script. Maybe an indication should be put in
> clusterdb.sgml that it should run separate from standard CLUSTER
> operations or from other runs of clusterdb?
>
> Sorry this took so long.
>
> --
> Alvaro Herrera (<alvherre[a]atentus.com>)
> "There was no reply" (Kernel Traffic)
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073