CLUSTER.

Read what the command CLUSTER does. Definately not what you think.
You create clustered indeces as you would any index:
create index lala_idx on lala (col1,col2,...);

cheers,
thalis

On Fri, 15 Jun 2001, Dariusz Pietrzak wrote:

Read what the command CLUSTER does. Definately not what you think.
You create clustered indeces as you would any index:
create index lala_idx on lala (col1,col2,...);

I already have indexes, now I want'em clustered.
Command: CLUSTER
Description: Gives storage clustering advice to the server

Problem is - this 'advice' seem to be pretty destructive.

I apologize for my earlier posting. I misinterpreted the term "clustered index".
It's done with CLUSTER indeed. Everything is copied in a temp table which is later renamed to the original table, so all grant perimissions and indeces are lost on this table. Also keep in mind that you'll get new OIDs too (if you are depending on them)

sorry,
thalis

---------- Forwarded message ----------
Date: Fri, 15 Jun 2001 11:32:53 -0400 (EDT)
From: Thalis A. Kalfigopoulos <thalis@cs.pitt.edu>
To: Dariusz Pietrzak <dariush@ajax.umcs.lublin.pl>
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] CLUSTER.

Read what the command CLUSTER does. Definately not what you think.
You create clustered indeces as you would any index:
create index lala_idx on lala (col1,col2,...);

cheers,
thalis

On Fri, 15 Jun 2001, Dariusz Pietrzak wrote:

I'm in the process of converting some embedded SQL code from ORACLE to
PostgreSQL and I'm running into some snags. I'm wondering if there is an
easy way to use the parameter names passed to a C function as variables in a
EXEC SQL command without having to declare the parameter names in a EXEC SQL
DECLARE section.

Here is a section of embedded SQL code that works fine in Oracle (some code
removed for brevity):

void open_database(char *user_name, char*pass_word)
{
EXEC SQL CONNECT :user_name IDENTIFIED BY :pass_word;
}

The only way I could get ecpg to process this code was to include a DECLARE
section, for example:

void open_database(char *user_name, char*pass_word)
{
EXEC SQL BEGIN DECLARE SECTION;
char *user_name;
char *pass_word;
EXEC SQL END DECLARE SECTION;
EXEC SQL CONNECT :user_name IDENTIFIED BY :pass_word;
}

Does anyone know of a workaround to allow use of the function parameters
without having to declare them first?

Thanks in advance,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

It's done with CLUSTER indeed. Everything is copied in a temp table which is later renamed to the original table, so all grant perimissions and indeces are lost on this table. Also keep in mind that you'll get new OIDs too (if you are depending on them)

Is very any way of going cluster without losing anything?
At this point I am able to dump/restore database, but soon it'll become
rather impossible for some time.
Do I have to 'cluster' before putting any data in dbase?

Clustering is really static i.e. it's done and after it any inserts/updates start spoiling the table again. So I guess the answer is no. Maybe you can create a procedure that does CLUSTER and then recreates the indeces and whatever else you lose in the process.

cheers,
thalis

On Fri, 15 Jun 2001, Dariusz Pietrzak wrote:

Clustering is really static i.e. it's done and after it any inserts/updates start spoiling the table again.
So I guess the answer is no. Maybe you can create a procedure that does
CLUSTER and then recreates the indeces and whatever else you lose in the
process.

What a pity,
I used to do some benchmarks and little studies using explain
and cluster had huge effect on efficency with data I used.
I thought it works like table partitions in oracle only within one data
location, pity.

Thanx.
--
Dariusz Pietrzak
Certified Nobody