For those who provided some guidance, I say "thank you." You comments
helped out a lot. All of our customers who are using the older
release are now very pleased with the performance of the database now
that we were able to give them meaningful configuration settings. I'm
also pleased to se
Todd,
> I'm going only on what my engineers are telling me, but they say
> upgrading breaks a lot of source code with some SQL commands that are
> a pain to hunt down and kill. Not sure if that's true, but that's
> what I'm told.
Depends on your app, but certainly that can be true. Oddly, 7.2 ->
On Thu, Jun 16, 2005 at 07:15:08PM -0700, Todd Landfried wrote:
> Thanks for the link. I'll look into those.
>
> I'm going only on what my engineers are telling me, but they say
> upgrading breaks a lot of source code with some SQL commands that are
> a pain to hunt down and kill. Not sure if
Thanks for the link. I'll look into those.
I'm going only on what my engineers are telling me, but they say
upgrading breaks a lot of source code with some SQL commands that are
a pain to hunt down and kill. Not sure if that's true, but that's
what I'm told.
Todd
On Jun 16, 2005, at 10:0
On Thu, Jun 16, 2005 at 07:46:45 -0700,
Todd Landfried <[EMAIL PROTECTED]> wrote:
> Yes, it is 7.2. Why? because an older version of our software runs on
> RH7.3 and that was the latest supported release of Postgresql for
> RH7.3 (that we can find). We're currently ported to 8, but we still
We run the RPM's for RH 7.3 on our 7.2 install base with no problems.
RPM's as recent as for PostgreSQL 7.4.2 are available here:
ftp://ftp10.us.postgresql.org/pub/postgresql/binary/v7.4.2/redhat/redhat-7.3/
Or you can always compile from source. There isn't any such thing as a
'supported' packag
Yes, it is 7.2. Why? because an older version of our software runs on
RH7.3 and that was the latest supported release of Postgresql for
RH7.3 (that we can find). We're currently ported to 8, but we still
have a large installed base with the other version.
On Jun 15, 2005, at 7:18 AM, Tom L
Dennis,
> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
>
> > NOTICE: shared_buffers is 256
For everyone's info, the current (8.0) version is at:
http://www.powerpostgresql.com/PerfList
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(en
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Wed, 15 Jun 2005, Todd Landfried wrote:
>> NOTICE: shared_buffers is 256
> This looks like it's way too low. Try something like 2048.
It also is evidently PG 7.2 or before; SHOW's output hasn't looked like
that in years. Try a more recent releas
On Wed, Jun 15, 2005 at 02:06:27 -0700,
Todd Landfried <[EMAIL PROTECTED]> wrote:
>
> What's the problem? The sucker gets s-l-o-w on relatively simple
> queries. For example, simply listing all of the users online at one
> time takes 30-45 seconds if we're talking about 800 users. We've
>
On Wed, 15 Jun 2005, Todd Landfried wrote:
> So, what I need is to be pointed to (or told) what are the best
> settings for our database given these memory configurations. What
> should we do?
Maybe this will help:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
> NOTICE: sha
I deeply apologize if this has been covered with some similar topic
before, but I need a little guidance in the optimization department.
We use Postgres as our database and we're having some issues dealing
with customers who are, shall we say, "thrifty" when it comes to
buying RAM.
We tel
12 matches
Mail list logo
