Curt Sampson | 1 Jul 04:50 2002
Picon

Re: [PATCHES] Reduce heap tuple header size

On Fri, 28 Jun 2002, Bruce Momjian wrote:

> OK, we need to vote on this patch.  It reduces the tuple header by 4
> bytes (11% decrease).
>
> If we apply it, we will not be able to easily use pg_upgrade for 7.3
> because the on-disk table format will change.
>
> Votes are:
>
> 1) Apply it now
> 2) Wait until August and see if any other table format changes are made.
> 3) Delay patch until we have other table format changes.

I would tend to say "apply it now" so that we can get more testing
of it.

It would also be good to see how else we could save space in the
header, e.g., by not having an empty OID field when a table is
created without OIDs. (That would double the space savings.)

I tend to use ID cross reference tables quite a lot, and these tend to
have a lot of rows in them. (E.g., group table has group ID; user table
has user-id; a group-id + user-id table determines which users are in
which groups. In one project a couple of years ago, such a table was 85
million rows.) These types of tables are typically 8 bytes of data and
40 or so bytes of overhead. Ouch!

cjs
--

-- 
(Continue reading)

Marc G. Fournier | 1 Jul 05:44 2002

Re: Are these groups "unauthorized"?

On Sat, 29 Jun 2002, Guido Ostkamp wrote:

> Tom Lane <tgl <at> sss.pgh.pa.us> wrote:
> > Guido Ostkamp <Guido.Ostkamp <at> gmx.de> writes:
> >> I am sure, a lot of people would be happy, if those groups were
> >> officially introduced and hosted on many international newservers.
> >
> > Yup.  Are you volunteering to be the proponent who shepherds a vote
> > through the official process?
>
> No.
>
> If you look closely at the 'comp.databases.*' hierarchy you will find
> that most of the databases listed have only one group, with the
> exception of the big players like Oracle.  That means, the maximum you
> would be able to get is a 'comp.databases.postgresql', but not the bunch
> of groups which is available here. I don't believe admins here would
> agree to throw away all others.
>
> What I recommend to do, is that the names of the groups here gets
> changed by stripping of the 'comp.databases' prefix. The group names
> would then make up their own main hierarchy ('postgres.*') like it
> exists for other stuff or companies as well (like 'microsoft.*') etc.
>
> That would AFAIK no longer violate any rules, and allow webmasters from
> outside to host these groups. Only the people reading these groups
> would need a small and easy reconfiguration of their subscribed lists
> which could be announced by a posting before its done, that's all.
>
> What do you think?
(Continue reading)

Christopher Kings-Lynne | 1 Jul 09:47 2002
Picon

DROP COLUMN Proposal

Hi All,

I've been thinking about this DROP COLUMN business (sorry to start another
spammy, flamey thread!).  I'm taking ideas from lots of sources here.

How does this sound for a process?

1.
A new column is added to pg_attribute called 'attisdropped'.  It, of course,
defaults to false.

2.
The column expansion (*) code and the code that checks for valid column
references everywhere in the codebase is changed to also check the
attisdropped field.  Does someone have a comprehensive list of places to be
changed?

3.
The DROP COLUMN command does nothing but set the attisdropped of a column to
true, and rename the column to something like DELETED_old_col_name.  The
column renaming will help people using non-attisdropped aware admin programs
see what's what, plus it will allow people to create a new column with the
same name as the column just dropped.

Now the dropped column will be invisible.  As you update rows, etc. the
space will be reclaimed in the table as NULLs are put in where the old value
used to be.  Is this correct?

4.
A new command, something like "ALTER TABLE tab RECLAIM;" will be able to be
(Continue reading)

Christopher Kings-Lynne | 1 Jul 09:50 2002
Picon

Re: [PATCHES] Changes in /contrib/fulltextindex

Hi Florian,

> > The most recent patches were submitted by me, so I guess you
> could call me
> > the defacto "maintainer".
>
> Okay - glad someone answered me :)

Actually, I replied to you 5 minutes after you posted, but I think my emails
were being stalled somewhere...

> I will - please give me a few days for an up to date documentation
> concerning the changed and new features.
>
> And yes - I really appreciate your offer for code review!

To generate the diff, do this:

cd contrib/fulltextindex
cvs diff -c > ftidiff.txt

Then email -hackers the ftidiff.txt.

> > > The changes made include:
> > >
> > > + Changed the split up behaviour from checking via isalpha to
> > >   using a list of delimiters as isalpha is a pain used with
> > >   data containing german umlauts, etc. ATM this list contains:
> > >
> > >   " ,;.:-_#/*+~^°!?\"\\§$%&()[]{}=<>|0123456789\n\r\t <at> µ"
(Continue reading)

Christopher Kings-Lynne | 1 Jul 10:32 2002
Picon

Re: DROP COLUMN Proposal

> 2.
> The column expansion (*) code and the code that checks for valid column
> references everywhere in the codebase is changed to also check the
> attisdropped field.  Does someone have a comprehensive list of
> places to be
> changed?

Actually - did Hiroshi(?)'s original HACK have this code - we can re-use
that.

Chris

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Hannu Krosing | 1 Jul 12:31 2002
Picon

Re: DROP COLUMN Proposal

On Mon, 2002-07-01 at 09:47, Christopher Kings-Lynne wrote:
> Hi All,
> 
> I've been thinking about this DROP COLUMN business (sorry to start another
> spammy, flamey thread!).  I'm taking ideas from lots of sources here.
> 
> How does this sound for a process?
> 
> 1.
> A new column is added to pg_attribute called 'attisdropped'.  It, of course,
> defaults to false.
> 
> 2.
> The column expansion (*) code and the code that checks for valid column
> references everywhere in the codebase is changed to also check the
> attisdropped field.  Does someone have a comprehensive list of places to be
> changed?

It seems at least easy to test/debug incrementally:

i.e put in the 'attisdropped' column with default 0 and _not_ the actual
DROP COLUMN command. then test by manually setting and unsetting it
until everything works, then switch on the command.

> 3.
> The DROP COLUMN command does nothing but set the attisdropped of a column to
> true, 

This will probably require a full lock on system tables to avoid nasty
border conditions when updating caches. But we probably have something
(Continue reading)

Manfred Koizar | 1 Jul 12:40 2002
Picon

HeapTupleHeader withoud oid

We have been discussing heap tuple header changes for a while now.
Here is my proposal for omitting the oid, when it is not needed:

First let's eliminate t_oid from HeapTupleHeaderData.

Then add the oid to the end of the structure, if and only if it is
needed.  The tricky part here is that there is a variable length field
(t_bits) and the oid has to be properly aligned.

This pseudo code snippet illustrates what I plan to do:

	len = offsetof(HeapTupleHeaderData, t_bits);  /* 23 */
	if (hasnulls) {
		len += BITMAPLEN(NumberOfAttributes);
	}
	if (hasoid) {
		len += sizeof(Oid);
	}
	len = MAXALIGN(len);
	hoff = len;
	oidoff = hoff - sizeof(Oid);

#define HeapTupleHeaderGetOid(hth) \
	( *((Oid *)((char *)(hth) + (hth)->t_hoff - sizeof(Oid))) )

And this is how the structure would look like:
               1         2           3
     0   4     0         0  34  78   2
now  oooo<---------fix--------->.x___X___
+oid <---------fix--------->.oooox___       MAXALIGN 4
(Continue reading)

Tom Lane | 1 Jul 15:28 2002
Picon

Re: [PATCHES] Changes in /contrib/fulltextindex

"Christopher Kings-Lynne" <chriskl <at> familyhealth.com.au> writes:
> Good idea.  Is there a locale-aware version of isalpha anywhere?
>> 
>> If there is - I couldn't find it. I did find a lot of frustated
>> posts about isalpha and locale-awareness although.

> Yeah, I can't find anything in the man pages either.  Maybe we can ask the
> list.  People?

Huh?  isalpha() *is* locale-aware according to the ANSI C spec.
For instance, the attached test program finds 52 alpha characters
in C locale and 114 in fr_FR locale under HPUX.

I am not at all sure that this aspect of Florian's change is a good
idea, as it appears to eliminate locale-awareness in favor of a hard
coded delimiter list.

			regards, tom lane

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <locale.h>

int main(int argc, char **argv)
{
  int i;

  setlocale(LC_ALL, "");

(Continue reading)

Tom Lane | 1 Jul 15:40 2002
Picon

Re: DROP COLUMN Proposal

Hannu Krosing <hannu <at> tm.ee> writes:
>> The DROP COLUMN command does nothing but set the attisdropped of a column to
>> true, 

> This will probably require a full lock on system tables to avoid nasty
> border conditions when updating caches.

AFAICS it's no different from any other ALTER TABLE command: exclusive
lock on the table being modified is necessary and sufficient.

>> Now the dropped column will be invisible.  As you update rows, etc. the
>> space will be reclaimed in the table as NULLs are put in where the old value
>> used to be. 

> You probably have to set DEFAULT for this column to NULL to achieve it.

Right, get rid of any default.

> And dropping / modifying indexes and constraints that reference the
> deleted column .

This part should fall out of Rod Taylor's pg_depend stuff pretty easily.
We still need to debate about the behavior, though.  If for example there
is a unique index on column B, do you need "DROP B CASCADE" to get rid
of it, or is "DROP B RESTRICT" good enough?  Does your answer change if
the unique index is on two columns (A,B)?  I'm not real sure where the
boundary is between attributes of the column (okay to drop as part of
the column) and independent objects that ought to be treated as
requiring CASCADE.

(Continue reading)

Florian Helmberger | 1 Jul 15:56 2002
Picon

Re: [PATCHES] Changes in /contrib/fulltextindex

Hi.

> Huh?  isalpha() *is* locale-aware according to the ANSI C spec.
> For instance, the attached test program finds 52 alpha characters
> in C locale and 114 in fr_FR locale under HPUX.
>
> I am not at all sure that this aspect of Florian's change is a good
> idea, as it appears to eliminate locale-awareness in favor of a hard
> coded delimiter list.

Just tried your example - you're right of course! I will remove the hard
coded delimited list and replace it with the proper calls as shown in the
code you've sent.

Florian

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org


Gmane