State of Beta 2

**Marc G. Fournier** · Nov 11 '05, 11:45 PM

Re: State of Beta 2

Beta2 is running archives.postgr esql.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:
[color=blue]
>
> 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.
> (740) 587-0114
> www.ravensfield.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)
>[/color]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

**Vivek Khera** · Nov 11 '05, 11:46 PM

Re: State of Beta 2

>>>>> "AR" == Andrew Rawnsley <ronz@ravensfie ld.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: khera@kciLink.c om Rockville, MD +1-240-453-8497
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 majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

**Vivek Khera** · Nov 11 '05, 11:46 PM

Re: State of Beta 2

>>>>> "AR" == Andrew Rawnsley <ronz@ravensfie ld.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: khera@kciLink.c om Rockville, MD +1-240-453-8497
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 majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

**scott.marlowe** · Nov 11 '05, 11:46 PM

Re: State of Beta 2

On Wed, 10 Sep 2003, Vivek Khera wrote:
[color=blue][color=green][color=darkred]
> >>>>> "AR" == Andrew Rawnsley <ronz@ravensfie ld.com> writes:[/color][/color]
>
> 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.[/color]

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** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

On Wed, 10 Sep 2003, Vivek Khera wrote:
[color=blue][color=green][color=darkred]
> >>>>> "AR" == Andrew Rawnsley <ronz@ravensfie ld.com> writes:[/color][/color]
>
> 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.[/color]

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** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

On Wed, 10 Sep 2003, Vivek Khera wrote:[color=blue]
> "AR" == Andrew Rawnsley <ronz@ravensfie ld.com> writes:[color=green]
>> 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.[/color][/color]

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** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

On Wed, 10 Sep 2003, Vivek Khera wrote:[color=blue]
> "AR" == Andrew Rawnsley <ronz@ravensfie ld.com> writes:[color=green]
>> 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.[/color][/color]

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** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

>>>>> "sm" == scott marlowe <scott.marlow e> writes:
[color=blue][color=green]
>> 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.[/color][/color]

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?

PostgreSQL: Not Found

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

**Vivek Khera** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

>>>>> "sm" == scott marlowe <scott.marlow e> writes:
[color=blue][color=green]
>> 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.[/color][/color]

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?

PostgreSQL: Not Found

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

**Marc G. Fournier** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

On Thu, 11 Sep 2003, Vivek Khera wrote:
[color=blue][color=green][color=darkred]
> >>>>> "sm" == scott marlowe <scott.marlow e> writes:[/color][/color]
>[color=green][color=darkred]
> >> 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.[/color][/color]
>
> 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.[/color]

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 majordomo@postg resql.org

**Marc G. Fournier** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

On Thu, 11 Sep 2003, Vivek Khera wrote:
[color=blue][color=green][color=darkred]
> >>>>> "sm" == scott marlowe <scott.marlow e> writes:[/color][/color]
>[color=green][color=darkred]
> >> 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.[/color][/color]
>
> 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.[/color]

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 majordomo@postg resql.org

**Vivek Khera** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

>>>>> "MGF" == Marc G Fournier <scrappy@postgr esql.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?

PostgreSQL: PostgreSQL Mailing List Archives

http://archives.postgresql.org

**Vivek Khera** · Nov 11 '05, 11:47 PM

Re: State of Beta 2

>>>>> "MGF" == Marc G Fournier <scrappy@postgr esql.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?

PostgreSQL: PostgreSQL Mailing List Archives

http://archives.postgresql.org

**Sean Chittenden** · Nov 11 '05, 11:48 PM

Re: State of Beta 2

> > >> I'm pondering doing the same, but I'm not 100% sure there won't[color=blue][color=green][color=darkred]
> > >> 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.[/color]
> >
> > 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.[/color]
>
> 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 ...[/color]

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 YourEmailAddres sHere" to majordomo@postg resql.org)