State of Beta 2

[Andrew Rawnsley]

Anyone out there using beta 2 in production situations? Comments on
stability? I am rolling out a project in the next 4 weeks, and really
don't want to go though an upgrade soon after its released on an
Unsuspecting Client, so I would LIKE to start working with 7.4.

--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
[phone]
www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Marc G. Fournier]

Beta2 is running archives.postgresql.org right now ... >4gig worth of
data, and seems to be performing pretty good, no crashes that I've been
made aware of ...

On Tue, 9 Sep 2003, Andrew Rawnsley wrote:

Anyone out there using beta 2 in production situations? Comments on
stability? I am rolling out a project in the next 4 weeks, and really
don't want to go though an upgrade soon after its released on an
Unsuspecting Client, so I would LIKE to start working with 7.4.

--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
[phone]
www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Vivek Khera]

>>>>> "AR" == Andrew Rawnsley <ro**@ravensfield.com> writes:

AR> Anyone out there using beta 2 in production situations? Comments on
AR> stability? I am rolling out a project in the next 4 weeks, and really
AR> don't want to go though an upgrade soon after its released on an
AR> Unsuspecting Client, so I would LIKE to start working with 7.4.

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD [phone]
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Vivek Khera]

>>>>> "AR" == Andrew Rawnsley <ro**@ravensfield.com> writes:

AR> Anyone out there using beta 2 in production situations? Comments on
AR> stability? I am rolling out a project in the next 4 weeks, and really
AR> don't want to go though an upgrade soon after its released on an
AR> Unsuspecting Client, so I would LIKE to start working with 7.4.

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD [phone]
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[scott.marlowe]

On Wed, 10 Sep 2003, Vivek Khera wrote:

>> "AR" == Andrew Rawnsley <ro**@ravensfield.com> writes:

AR> Anyone out there using beta 2 in production situations? Comments on
AR> stability? I am rolling out a project in the next 4 weeks, and really
AR> don't want to go though an upgrade soon after its released on an
AR> Unsuspecting Client, so I would LIKE to start working with 7.4.

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

Yeah, right now it's looking like the only thing you'll have to do is
reindex hash indexes between beta2 and beta3.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[scott.marlowe]

On Wed, 10 Sep 2003, Vivek Khera wrote:

>> "AR" == Andrew Rawnsley <ro**@ravensfield.com> writes:

AR> Anyone out there using beta 2 in production situations? Comments on
AR> stability? I am rolling out a project in the next 4 weeks, and really
AR> don't want to go though an upgrade soon after its released on an
AR> Unsuspecting Client, so I would LIKE to start working with 7.4.

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

Yeah, right now it's looking like the only thing you'll have to do is
reindex hash indexes between beta2 and beta3.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

On Wed, 10 Sep 2003, Vivek Khera wrote:

"AR" == Andrew Rawnsley <ro**@ravensfield.com> writes:

AR> Anyone out there using beta 2 in production situations?

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold.

As you shouldn't be ...

There's some major-league whining going on right now in the jdbc list
about the fact that "int8col = 42" isn't indexable. While we know that
solving this problem in the general case is hard, it occurred to me this
afternoon that fixing it just for int8 might not be so hard --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,
if it seems to help that situation without introducing other issues.
It's not well tested as yet, but stay tuned ...

regards, tom lane

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

[Tom Lane]

On Wed, 10 Sep 2003, Vivek Khera wrote:

"AR" == Andrew Rawnsley <ro**@ravensfield.com> writes:

AR> Anyone out there using beta 2 in production situations?

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold.

As you shouldn't be ...

There's some major-league whining going on right now in the jdbc list
about the fact that "int8col = 42" isn't indexable. While we know that
solving this problem in the general case is hard, it occurred to me this
afternoon that fixing it just for int8 might not be so hard --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,
if it seems to help that situation without introducing other issues.
It's not well tested as yet, but stay tuned ...

regards, tom lane

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

[Vivek Khera]

>>>>> "sm" == scott marlowe <scott.marlowe> writes:

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

sm> Yeah, right now it's looking like the only thing you'll have to do is
sm> reindex hash indexes between beta2 and beta3.
Sean had grumbled something about making pagesize 16k on FreeBSD for
7.4 but it seems unlikely. I'll just locally patch it since it does
seem to offer some improvement.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Vivek Khera]

>>>>> "sm" == scott marlowe <scott.marlowe> writes:

I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

sm> Yeah, right now it's looking like the only thing you'll have to do is
sm> reindex hash indexes between beta2 and beta3.
Sean had grumbled something about making pagesize 16k on FreeBSD for
7.4 but it seems unlikely. I'll just locally patch it since it does
seem to offer some improvement.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Marc G. Fournier]

On Thu, 11 Sep 2003, Vivek Khera wrote:

>> "sm" == scott marlowe <scott.marlowe> writes: I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

sm> Yeah, right now it's looking like the only thing you'll have to do is
sm> reindex hash indexes between beta2 and beta3.
Sean had grumbled something about making pagesize 16k on FreeBSD for
7.4 but it seems unlikely. I'll just locally patch it since it does
seem to offer some improvement.

Without a fair amount of testing, especially on other platforms, it most
likely won't happen in the distribution itself ... one of the things that
was bantered around for after v7.4 is released is seeing how increasing it
on the various platforms fairs, and possibly just raising the default to
16k or 32k (Tatsuo mentioned a 15% improvement at 32k) ...

But, we'll need broader testing before that happens ...

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Marc G. Fournier]

On Thu, 11 Sep 2003, Vivek Khera wrote:

>> "sm" == scott marlowe <scott.marlowe> writes: I'm pondering doing the same, but I'm not 100% sure there won't be any
dump/restore-required changes to it before it goes gold. From my
tuning tests I've been running on it, it appears to be extremely fast
and stable.

sm> Yeah, right now it's looking like the only thing you'll have to do is
sm> reindex hash indexes between beta2 and beta3.
Sean had grumbled something about making pagesize 16k on FreeBSD for
7.4 but it seems unlikely. I'll just locally patch it since it does
seem to offer some improvement.

Without a fair amount of testing, especially on other platforms, it most
likely won't happen in the distribution itself ... one of the things that
was bantered around for after v7.4 is released is seeing how increasing it
on the various platforms fairs, and possibly just raising the default to
16k or 32k (Tatsuo mentioned a 15% improvement at 32k) ...

But, we'll need broader testing before that happens ...

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Vivek Khera]

>>>>> "MGF" == Marc G Fournier <sc*****@postgresql.org> writes:

MGF> Without a fair amount of testing, especially on other platforms, it most
MGF> likely won't happen in the distribution itself ... one of the things that
MGF> was bantered around for after v7.4 is released is seeing how increasing it
MGF> on the various platforms fairs, and possibly just raising the default to
MGF> 16k or 32k (Tatsuo mentioned a 15% improvement at 32k) ...

MGF> But, we'll need broader testing before that happens ...

Well... if we had a good load generator (many threads; many small,
medium, large transactions; many inserts; many reads) I'd run it to
death on my idle server until 7.4 is released, at which point that
server won't be idle anymore.

I tried building one of the OSDL DB benchmark, but after installing
the dependencies which are only announced by the failure of configure
to run, it errored out with a C syntax error... at that point I gave
up.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Vivek Khera]

>>>>> "MGF" == Marc G Fournier <sc*****@postgresql.org> writes:

MGF> Without a fair amount of testing, especially on other platforms, it most
MGF> likely won't happen in the distribution itself ... one of the things that
MGF> was bantered around for after v7.4 is released is seeing how increasing it
MGF> on the various platforms fairs, and possibly just raising the default to
MGF> 16k or 32k (Tatsuo mentioned a 15% improvement at 32k) ...

MGF> But, we'll need broader testing before that happens ...

Well... if we had a good load generator (many threads; many small,
medium, large transactions; many inserts; many reads) I'd run it to
death on my idle server until 7.4 is released, at which point that
server won't be idle anymore.

I tried building one of the OSDL DB benchmark, but after installing
the dependencies which are only announced by the failure of configure
to run, it errored out with a C syntax error... at that point I gave
up.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Sean Chittenden]

> > >> I'm pondering doing the same, but I'm not 100% sure there won't

> be any dump/restore-required changes to it before it goes gold.
> From my tuning tests I've been running on it, it appears to be
> extremely fast and stable.

sm> Yeah, right now it's looking like the only thing you'll have to do is
sm> reindex hash indexes between beta2 and beta3.

Sean had grumbled something about making pagesize 16k on FreeBSD
for 7.4 but it seems unlikely. I'll just locally patch it since
it does seem to offer some improvement.

Without a fair amount of testing, especially on other platforms, it
most likely won't happen in the distribution itself ... one of the
things that was bantered around for after v7.4 is released is seeing
how increasing it on the various platforms fairs, and possibly just
raising the default to 16k or 32k (Tatsuo mentioned a 15%
improvement at 32k) ...

But, we'll need broader testing before that happens ...

I haven't had a chance to sit down and do any exhaustive testing yet
and don't think I will for a while. That said, once 7.4 goes gold,
I'm going to provide databases/postgresql-devel with a tunable that
will allow people to choose what block size they would like (4k, 8K,
16K, 32K, or 64K) when they build the port. Hopefully people will
chime in with their results at that time. With things so close to 7.4
and Tom worried about digging up possible bugs, I'm not about to
destabilize 7.4 for FreeBSD users.

I'm personally under the gut feeling that 8K or 4K block sizes will be
a win for some loads, but bigger block sizes will result in more
efficient over all operations in cases where IO is more expensive than
CPU (which changes with hardware and workload).

In the future table spaces implementation, I think it would be a HUGE
win for DBAs if the block size could be specified on a per table
basis. I know that won't be an easy change, but I do think it would
be beneficial for different work loads and filesystems.

-sc

--
Sean Chittenden

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Sean Chittenden]

> > >> I'm pondering doing the same, but I'm not 100% sure there won't

> be any dump/restore-required changes to it before it goes gold.
> From my tuning tests I've been running on it, it appears to be
> extremely fast and stable.

sm> Yeah, right now it's looking like the only thing you'll have to do is
sm> reindex hash indexes between beta2 and beta3.

Sean had grumbled something about making pagesize 16k on FreeBSD
for 7.4 but it seems unlikely. I'll just locally patch it since
it does seem to offer some improvement.

Without a fair amount of testing, especially on other platforms, it
most likely won't happen in the distribution itself ... one of the
things that was bantered around for after v7.4 is released is seeing
how increasing it on the various platforms fairs, and possibly just
raising the default to 16k or 32k (Tatsuo mentioned a 15%
improvement at 32k) ...

But, we'll need broader testing before that happens ...

I haven't had a chance to sit down and do any exhaustive testing yet
and don't think I will for a while. That said, once 7.4 goes gold,
I'm going to provide databases/postgresql-devel with a tunable that
will allow people to choose what block size they would like (4k, 8K,
16K, 32K, or 64K) when they build the port. Hopefully people will
chime in with their results at that time. With things so close to 7.4
and Tom worried about digging up possible bugs, I'm not about to
destabilize 7.4 for FreeBSD users.

I'm personally under the gut feeling that 8K or 4K block sizes will be
a win for some loads, but bigger block sizes will result in more
efficient over all operations in cases where IO is more expensive than
CPU (which changes with hardware and workload).

In the future table spaces implementation, I think it would be a HUGE
win for DBAs if the block size could be specified on a per table
basis. I know that won't be an easy change, but I do think it would
be beneficial for different work loads and filesystems.

-sc

--
Sean Chittenden

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Marc G. Fournier]

I haven't had a chance to sit down and do any exhaustive testing yet and
don't think I will for a while. That said, once 7.4 goes gold, I'm
going to provide databases/postgresql-devel with a tunable that will
allow people to choose what block size they would like (4k, 8K, 16K,
32K, or 64K) when they build the port.

If you do this, you *have* to put in a very very big warning that
databases created with non-PostgreSQL-standard block sizes may not be
transferrable to a standard-PostgreSQL install ... that is Tom's major
problem, is cross-platform/system dump/restores may no work is the
database schema was designed with a 16k block size in mind ...
---------------------------(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

[Marc G. Fournier]

I haven't had a chance to sit down and do any exhaustive testing yet and
don't think I will for a while. That said, once 7.4 goes gold, I'm
going to provide databases/postgresql-devel with a tunable that will
allow people to choose what block size they would like (4k, 8K, 16K,
32K, or 64K) when they build the port.

If you do this, you *have* to put in a very very big warning that
databases created with non-PostgreSQL-standard block sizes may not be
transferrable to a standard-PostgreSQL install ... that is Tom's major
problem, is cross-platform/system dump/restores may no work is the
database schema was designed with a 16k block size in mind ...
---------------------------(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

[Sean Chittenden]

> > I haven't had a chance to sit down and do any exhaustive testing

yet and don't think I will for a while. That said, once 7.4 goes
gold, I'm going to provide databases/postgresql-devel with a
tunable that will allow people to choose what block size they
would like (4k, 8K, 16K, 32K, or 64K) when they build the port.
If you do this, you *have* to put in a very very big warning that
databases created with non-PostgreSQL-standard block sizes may not
be transferrable to a standard-PostgreSQL install ... that is Tom's
major problem, is cross-platform/system dump/restores may no work is
the database schema was designed with a 16k block size in mind ...

Agreed, but if anyone has a table with close to 1600 columns in a
table... is either nuts or knows what they're doing. If someone has1600 columns, that is an issue, but isn't one that I think can be

easily fended off without the backend being able to adapt on the fly
to different block sizes, which seems like something that could be
done with a rewrite of some of this code when table spaces are
introduced.

-sc

--
Sean Chittenden

---------------------------(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

[Sean Chittenden]

> > I haven't had a chance to sit down and do any exhaustive testing

yet and don't think I will for a while. That said, once 7.4 goes
gold, I'm going to provide databases/postgresql-devel with a
tunable that will allow people to choose what block size they
would like (4k, 8K, 16K, 32K, or 64K) when they build the port.
If you do this, you *have* to put in a very very big warning that
databases created with non-PostgreSQL-standard block sizes may not
be transferrable to a standard-PostgreSQL install ... that is Tom's
major problem, is cross-platform/system dump/restores may no work is
the database schema was designed with a 16k block size in mind ...

Agreed, but if anyone has a table with close to 1600 columns in a
table... is either nuts or knows what they're doing. If someone has1600 columns, that is an issue, but isn't one that I think can be

easily fended off without the backend being able to adapt on the fly
to different block sizes, which seems like something that could be
done with a rewrite of some of this code when table spaces are
introduced.

-sc

--
Sean Chittenden

---------------------------(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

[Manfred Koizar]

On Thu, 11 Sep 2003 14:24:25 -0700, Sean Chittenden
<se**@chittenden.org> wrote:

Agreed, but if anyone has a table with close to 1600 columns in a
table...

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Manfred Koizar]

On Thu, 11 Sep 2003 14:24:25 -0700, Sean Chittenden
<se**@chittenden.org> wrote:

Agreed, but if anyone has a table with close to 1600 columns in a
table...

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Bruce Momjian]

Manfred Koizar wrote:

On Thu, 11 Sep 2003 14:24:25 -0700, Sean Chittenden
<se**@chittenden.org> wrote:

Agreed, but if anyone has a table with close to 1600 columns in a
table...

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure. Then our max would be:

255 * 8 = 2040

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Bruce Momjian]

Manfred Koizar wrote:

On Thu, 11 Sep 2003 14:24:25 -0700, Sean Chittenden
<se**@chittenden.org> wrote:

Agreed, but if anyone has a table with close to 1600 columns in a
table...

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure. Then our max would be:

255 * 8 = 2040

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Manfred Koizar]

On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

"int8col = 42" isn't indexable. [...] --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,

You mean

DELETE FROM pg_operator WHERE oid in (15, 36, 416, 417);

and possibly some more oids? Does this really require an initdb? If
we were willing to tell people who roll a 7.4Beta2 database cluster
into 7.4Beta3 (or 7.4 production) to execute this query once per
database, we could get away without increasing CATALOG_VERSION_NO.

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Manfred Koizar]

On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

"int8col = 42" isn't indexable. [...] --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,

You mean

DELETE FROM pg_operator WHERE oid in (15, 36, 416, 417);

and possibly some more oids? Does this really require an initdb? If
we were willing to tell people who roll a 7.4Beta2 database cluster
into 7.4Beta3 (or 7.4 production) to execute this query once per
database, we could get away without increasing CATALOG_VERSION_NO.

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Tom Lane]

Manfred Koizar <mk*****@aon.at> writes:

On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

"int8col = 42" isn't indexable. [...] --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,

You mean
DELETE FROM pg_operator WHERE oid in (15, 36, 416, 417);
and possibly some more oids? Does this really require an initdb?

I think so. Consider for instance stored views that contain references
to those operators. In any case, I don't really want to have to ask
people who complain about 7.4 performance problems whether they've done
the above.

regards, tom lane

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

[Tom Lane]

Manfred Koizar <mk*****@aon.at> writes:

On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

"int8col = 42" isn't indexable. [...] --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,

You mean
DELETE FROM pg_operator WHERE oid in (15, 36, 416, 417);
and possibly some more oids? Does this really require an initdb?

I think so. Consider for instance stored views that contain references
to those operators. In any case, I don't really want to have to ask
people who complain about 7.4 performance problems whether they've done
the above.

regards, tom lane

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

[Manfred Koizar]

On Fri, 12 Sep 2003 10:22:32 -0400 (EDT), Bruce Momjian <pg***@candle.pha.pa.us>
wrote:

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure.

No, never! ;-)

Sollte einer auch einst die vollkommenste Wahrheit verkünden,
Wissen könnt' er das nicht: Es ist alles durchwebt von Vermutung.

For even if by chance he were to utter the final truth,
He would himself not know it: For it is but a woven web of guesses.
-- Xenophanes, translation by K. R. Popper

But in this case I have htup.h on my side:

/*
* MaxTupleAttributeNumber limits the number of (user) columns in a tuple.
* The key limit on this value is that the size of the fixed overhead for
* a tuple, plus the size of the null-values bitmap (at 1 bit per column),
* plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most
* machines the upper limit without making t_hoff wider would be a little
* over 1700. We use round numbers here and for MaxHeapAttributeNumber
* so that alterations in HeapTupleHeaderData layout won't change the
* supported max number of columns.
*/
#define MaxTupleAttributeNumber 1664 /* 8 * 208 */

/*----------
* MaxHeapAttributeNumber limits the number of (user) columns in a table.
* This should be somewhat less than MaxTupleAttributeNumber. It must be
* at least one less, else we will fail to do UPDATEs on a maximal-width
* table (because UPDATE has to form working tuples that include CTID).
* In practice we want some additional daylight so that we can gracefully
* support operations that add hidden "resjunk" columns, for example
* SELECT * FROM wide_table ORDER BY foo, bar, baz.
* In any case, depending on column data types you will likely be running
* into the disk-block-based limit on overall tuple size if you have more
* than a thousand or so columns. TOAST won't help.
*----------
*/
#define MaxHeapAttributeNumber 1600 /* 8 * 200 */

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Manfred Koizar]

On Fri, 12 Sep 2003 10:22:32 -0400 (EDT), Bruce Momjian <pg***@candle.pha.pa.us>
wrote:

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure.

No, never! ;-)

Sollte einer auch einst die vollkommenste Wahrheit verkünden,
Wissen könnt' er das nicht: Es ist alles durchwebt von Vermutung.

For even if by chance he were to utter the final truth,
He would himself not know it: For it is but a woven web of guesses.
-- Xenophanes, translation by K. R. Popper

But in this case I have htup.h on my side:

/*
* MaxTupleAttributeNumber limits the number of (user) columns in a tuple.
* The key limit on this value is that the size of the fixed overhead for
* a tuple, plus the size of the null-values bitmap (at 1 bit per column),
* plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most
* machines the upper limit without making t_hoff wider would be a little
* over 1700. We use round numbers here and for MaxHeapAttributeNumber
* so that alterations in HeapTupleHeaderData layout won't change the
* supported max number of columns.
*/
#define MaxTupleAttributeNumber 1664 /* 8 * 208 */

/*----------
* MaxHeapAttributeNumber limits the number of (user) columns in a table.
* This should be somewhat less than MaxTupleAttributeNumber. It must be
* at least one less, else we will fail to do UPDATEs on a maximal-width
* table (because UPDATE has to form working tuples that include CTID).
* In practice we want some additional daylight so that we can gracefully
* support operations that add hidden "resjunk" columns, for example
* SELECT * FROM wide_table ORDER BY foo, bar, baz.
* In any case, depending on column data types you will likely be running
* into the disk-block-based limit on overall tuple size if you have more
* than a thousand or so columns. TOAST won't help.
*----------
*/
#define MaxHeapAttributeNumber 1600 /* 8 * 200 */

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Bruce Momjian]

Manfred Koizar wrote:

On Fri, 12 Sep 2003 10:22:32 -0400 (EDT), Bruce Momjian <pg***@candle.pha.pa.us>
wrote:

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure.

No, never! ;-)

Sollte einer auch einst die vollkommenste Wahrheit verk?nden,
Wissen k?nnt' er das nicht: Es ist alles durchwebt von Vermutung.

For even if by chance he were to utter the final truth,
He would himself not know it: For it is but a woven web of guesses.
-- Xenophanes, translation by K. R. Popper

But in this case I have htup.h on my side:

/*
* MaxTupleAttributeNumber limits the number of (user) columns in a tuple.
* The key limit on this value is that the size of the fixed overhead for
* a tuple, plus the size of the null-values bitmap (at 1 bit per column),
* plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most
* machines the upper limit without making t_hoff wider would be a little
* over 1700. We use round numbers here and for MaxHeapAttributeNumber
* so that alterations in HeapTupleHeaderData layout won't change the
* supported max number of columns.
*/
#define MaxTupleAttributeNumber 1664 /* 8 * 208 */

/*----------
* MaxHeapAttributeNumber limits the number of (user) columns in a table.
* This should be somewhat less than MaxTupleAttributeNumber. It must be
* at least one less, else we will fail to do UPDATEs on a maximal-width
* table (because UPDATE has to form working tuples that include CTID).
* In practice we want some additional daylight so that we can gracefully
* support operations that add hidden "resjunk" columns, for example
* SELECT * FROM wide_table ORDER BY foo, bar, baz.
* In any case, depending on column data types you will likely be running
* into the disk-block-based limit on overall tuple size if you have more
* than a thousand or so columns. TOAST won't help.
*----------
*/
#define MaxHeapAttributeNumber 1600 /* 8 * 200 */

Oh, interesting. I thought it was based on the maximum number of
columns we could pack into a block. I realize that our limit could be
much less than 1600 if you pick wide columns like TEXT.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

[Bruce Momjian]

Manfred Koizar wrote:

On Fri, 12 Sep 2003 10:22:32 -0400 (EDT), Bruce Momjian <pg***@candle.pha.pa.us>
wrote:

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure.

No, never! ;-)

Sollte einer auch einst die vollkommenste Wahrheit verk?nden,
Wissen k?nnt' er das nicht: Es ist alles durchwebt von Vermutung.

For even if by chance he were to utter the final truth,
He would himself not know it: For it is but a woven web of guesses.
-- Xenophanes, translation by K. R. Popper

But in this case I have htup.h on my side:

/*
* MaxTupleAttributeNumber limits the number of (user) columns in a tuple.
* The key limit on this value is that the size of the fixed overhead for
* a tuple, plus the size of the null-values bitmap (at 1 bit per column),
* plus MAXALIGN alignment, must fit into t_hoff which is uint8. On most
* machines the upper limit without making t_hoff wider would be a little
* over 1700. We use round numbers here and for MaxHeapAttributeNumber
* so that alterations in HeapTupleHeaderData layout won't change the
* supported max number of columns.
*/
#define MaxTupleAttributeNumber 1664 /* 8 * 208 */

/*----------
* MaxHeapAttributeNumber limits the number of (user) columns in a table.
* This should be somewhat less than MaxTupleAttributeNumber. It must be
* at least one less, else we will fail to do UPDATEs on a maximal-width
* table (because UPDATE has to form working tuples that include CTID).
* In practice we want some additional daylight so that we can gracefully
* support operations that add hidden "resjunk" columns, for example
* SELECT * FROM wide_table ORDER BY foo, bar, baz.
* In any case, depending on column data types you will likely be running
* into the disk-block-based limit on overall tuple size if you have more
* than a thousand or so columns. TOAST won't help.
*----------
*/
#define MaxHeapAttributeNumber 1600 /* 8 * 200 */

Oh, interesting. I thought it was based on the maximum number of
columns we could pack into a block. I realize that our limit could be
much less than 1600 if you pick wide columns like TEXT.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

[Tom Lane]

Manfred Koizar <mk*****@aon.at> writes:

On Thu, 11 Sep 2003 14:24:25 -0700, Sean Chittenden
<se**@chittenden.org> wrote:

Agreed, but if anyone has a table with close to 1600 columns in a
table...

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Right, but that's not the only limit on number of columns. A tuple has
to be able to fit into a page. If all your columns are toastable types,
and you toast every one of them, then the toast pointers are 20 bytes
each, so with 8K block size the maximum usable number of columns is
somewhere around 400. If the columns were all int8 or float8 the limit
would be about 1000 columns; etc. But raise the page size, and these
limits increase, possibly allowing the 1600 number to become the actual
limiting factor.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Tom Lane]

Manfred Koizar <mk*****@aon.at> writes:

On Thu, 11 Sep 2003 14:24:25 -0700, Sean Chittenden
<se**@chittenden.org> wrote:

Agreed, but if anyone has a table with close to 1600 columns in a
table...

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Right, but that's not the only limit on number of columns. A tuple has
to be able to fit into a page. If all your columns are toastable types,
and you toast every one of them, then the toast pointers are 20 bytes
each, so with 8K block size the maximum usable number of columns is
somewhere around 400. If the columns were all int8 or float8 the limit
would be about 1000 columns; etc. But raise the page size, and these
limits increase, possibly allowing the 1600 number to become the actual
limiting factor.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Tom Lane]

Bruce Momjian <pg***@candle.pha.pa.us> writes:

Manfred Koizar wrote:

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure. Then our max would be:
255 * 8 = 2040

I assure you, Manfred knows heap tuple headers inside and out ;-)
See the comments at the top of src/include/access/htup.h.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Bruce Momjian <pg***@candle.pha.pa.us> writes:

Manfred Koizar wrote:

This 1600 column limit has nothing to do with block size. It is
caused by the fact that a heap tuple header cannot be larger than 255
bytes, so there is a limited number of bits in the null bitmap.

Are you sure. Then our max would be:
255 * 8 = 2040

I assure you, Manfred knows heap tuple headers inside and out ;-)
See the comments at the top of src/include/access/htup.h.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Andrew Rawnsley]

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

I am, of course, speaking from near-complete ignorance about what it
takes to avoid the whole problem.
On Friday, September 12, 2003, at 10:37 AM, Tom Lane wrote:

Manfred Koizar <mk*****@aon.at> writes:

On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

"int8col = 42" isn't indexable. [...] --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,

You mean
DELETE FROM pg_operator WHERE oid in (15, 36, 416, 417);
and possibly some more oids? Does this really require an initdb?

I think so. Consider for instance stored views that contain references
to those operators. In any case, I don't really want to have to ask
people who complain about 7.4 performance problems whether they've done
the above.

regards, tom lane

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

--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
[phone]
www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Andrew Rawnsley]

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

I am, of course, speaking from near-complete ignorance about what it
takes to avoid the whole problem.
On Friday, September 12, 2003, at 10:37 AM, Tom Lane wrote:

Manfred Koizar <mk*****@aon.at> writes:

On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

"int8col = 42" isn't indexable. [...] --- maybe
just taking out the int8-vs-int4 comparison operators would improve
matters. I might be willing to advocate another initdb to do that,

You mean
DELETE FROM pg_operator WHERE oid in (15, 36, 416, 417);
and possibly some more oids? Does this really require an initdb?

I think so. Consider for instance stored views that contain references
to those operators. In any case, I don't really want to have to ask
people who complain about 7.4 performance problems whether they've done
the above.

regards, tom lane

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

--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
[phone]
www.ravensfield.com
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Manfred Koizar]

On Fri, 12 Sep 2003 11:16:58 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

This 1600 column limit has nothing to do with block size.
Right, but that's not the only limit on number of columns.

I just wanted to make clear that increasing page size does not enable
you to get beyond that 1600 column limit. This not so uncommon
misbelief is ... well, I wouldn't say caused, but at least not
contradicted by
http://www.postgresql.org/users-lounge/limitations.html

| Maximum number of 250 - 1600 depending
| columns in a table on column types
| [...]
| The maximum table size and maximum number of columns can be
| increased if the default block size is increased to 32k.
But raise the page size, and these
limits increase, possibly allowing the 1600 number to become the actual
limiting factor.

Theoretically with int2 or "char" columns the 1600 columns limit can
be reached even without changing the page size. Figuring out a use
case for such a table is another story ...

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Manfred Koizar]

On Fri, 12 Sep 2003 11:16:58 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

This 1600 column limit has nothing to do with block size.
Right, but that's not the only limit on number of columns.

I just wanted to make clear that increasing page size does not enable
you to get beyond that 1600 column limit. This not so uncommon
misbelief is ... well, I wouldn't say caused, but at least not
contradicted by
http://www.postgresql.org/users-lounge/limitations.html

| Maximum number of 250 - 1600 depending
| columns in a table on column types
| [...]
| The maximum table size and maximum number of columns can be
| increased if the default block size is increased to 32k.
But raise the page size, and these
limits increase, possibly allowing the 1600 number to become the actual
limiting factor.

Theoretically with int2 or "char" columns the 1600 columns limit can
be reached even without changing the page size. Figuring out a use
case for such a table is another story ...

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Manfred Koizar]

On Fri, 12 Sep 2003 10:37:20 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

int8-vs-int4 comparison operators

Consider for instance stored views that contain references
to those operators.

I'm not able to produce a test case for what I think you mean; must
have missed something. Doesn't matter. Just move on ...

Servus
Manfred

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

[Manfred Koizar]

On Fri, 12 Sep 2003 10:37:20 -0400, Tom Lane <tg*@sss.pgh.pa.us>
wrote:

int8-vs-int4 comparison operators

Consider for instance stored views that contain references
to those operators.

I'm not able to produce a test case for what I think you mean; must
have missed something. Doesn't matter. Just move on ...

Servus
Manfred

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

[Ron Johnson]

On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

And this will become even more of an issue as it's PG's popularity
grows with large and 24x7 databases.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

An ad run by the NEA (the US's biggest public school TEACHERS
UNION) in the Spring and Summer of 2003 asks a teenager if he
can find sodium and *chloride* in the periodic table of the elements.
And they wonder why people think public schools suck...
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Ron Johnson]

On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

And this will become even more of an issue as it's PG's popularity
grows with large and 24x7 databases.

--
-----------------------------------------------------------------
Ron Johnson, Jr. ro***********@cox.net
Jefferson, LA USA

An ad run by the NEA (the US's biggest public school TEACHERS
UNION) in the Spring and Summer of 2003 asks a teenager if he
can find sodium and *chloride* in the periodic table of the elements.
And they wonder why people think public schools suck...
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Nigel J. Andrews]

On Fri, 12 Sep 2003, Ron Johnson wrote:

On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

And this will become even more of an issue as it's PG's popularity
grows with large and 24x7 databases.

And dump/reload isn't always such a casual operation to do. I initialise a
database from dump but I have to fiddle the sql on the reload to make it work.
The odd thing is I never thought it a bug, just something to work around, until
someone else has been persuing it on the list as one (it's the create schema
thing).
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Nigel J. Andrews]

On Fri, 12 Sep 2003, Ron Johnson wrote:

On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

And this will become even more of an issue as it's PG's popularity
grows with large and 24x7 databases.

And dump/reload isn't always such a casual operation to do. I initialise a
database from dump but I have to fiddle the sql on the reload to make it work.
The odd thing is I never thought it a bug, just something to work around, until
someone else has been persuing it on the list as one (it's the create schema
thing).
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Dennis Gearon]

Ron Johnson wrote:

On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

And this will become even more of an issue as it's PG's popularity
grows with large and 24x7 databases.

He is right, it might be a good idea to head this problem 'off at the
pass'. I am usually pretty good at predicting technilogical trends. I've
made some money at it. And I predict that Postgres will eclipse MySQL
and be in the top 5 of all databases deployed. But it does have some
achilles tendon's.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Dennis Gearon]

Ron Johnson wrote:

On Fri, 2003-09-12 at 10:50, Andrew Rawnsley wrote:

Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

And this will become even more of an issue as it's PG's popularity
grows with large and 24x7 databases.

He is right, it might be a good idea to head this problem 'off at the
pass'. I am usually pretty good at predicting technilogical trends. I've
made some money at it. And I predict that Postgres will eclipse MySQL
and be in the top 5 of all databases deployed. But it does have some
achilles tendon's.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Kaare Rasmussen]

> He is right, it might be a good idea to head this problem 'off at the

pass'. I am usually pretty good at predicting technilogical trends. I've

Well, the only solution I can see is to make an inline conversion tool that
knows about every step from earlier versions.

I believe this has been discussed before, but it does not seem to be a small
or an easy task to implement.

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: [phone]
Howitzvej 75 Åben 12.00-18.00 Email: ka*@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Kaare Rasmussen]

> He is right, it might be a good idea to head this problem 'off at the

pass'. I am usually pretty good at predicting technilogical trends. I've

Well, the only solution I can see is to make an inline conversion tool that
knows about every step from earlier versions.

I believe this has been discussed before, but it does not seem to be a small
or an easy task to implement.

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: [phone]
Howitzvej 75 Åben 12.00-18.00 Email: ka*@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings