indisclustered and clusterdb

Started by Alvaro Herreraalmost 24 years ago10 messagespatches
Jump to latest
#1Alvaro Herrera
alvherre@atentus.com

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)

Attachments:

clusterdb.patchtext/plain; charset=US-ASCII; name=clusterdb.patchDownload+48-6
clusterdbtext/plain; charset=US-ASCII; name=clusterdbDownload
clusterdb.sgmltext/plain; charset=US-ASCII; name=clusterdb.sgmlDownload
#2Bruce Momjian
bruce@momjian.us
In reply to: Alvaro Herrera (#1)
Re: indisclustered and clusterdb

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
#3Bruce Momjian
bruce@momjian.us
In reply to: Alvaro Herrera (#1)
Re: indisclustered and clusterdb

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
#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alvaro Herrera (#1)
Re: indisclustered and clusterdb

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

#5Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#4)
Re: indisclustered and clusterdb

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
#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#5)
Re: indisclustered and clusterdb

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

#7Alvaro Herrera
alvherre@atentus.com
In reply to: Tom Lane (#4)
Re: indisclustered and clusterdb

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)

#8Alvaro Herrera
alvherre@atentus.com
In reply to: Tom Lane (#4)
Re: indisclustered and clusterdb

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)

Attachments:

clusterdb.patchapplication/octet-stream; name=clusterdb.patchDownload+38-32
#9Bruce Momjian
bruce@momjian.us
In reply to: Alvaro Herrera (#8)
Re: indisclustered and clusterdb

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
#10Bruce Momjian
bruce@momjian.us
In reply to: Alvaro Herrera (#8)
Re: indisclustered and clusterdb

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