the bloat is a big problem. i just checked it again, and the db has
balloooned to 20 megs again, with i think 2650 unused pages. this is after
vacuuming it last night. i guess we need to setup the vacuum script to run
every hour. i am worried about this locking out users during the
vacuuming,
LinuxCare runs a comparison chart and poll about different databases
available for Linux
http://www.linuxcare.com/products/prodmore.epl?PRODUCT_GROUP=Relational+Database+Management+Systems
--
Alessio F. Bragadini[EMAIL PROTECTED]
APL Financial Services
On Fri, Apr 14, 2000 at 03:44:09PM +0900, Tatsuo Ishii wrote:
Oh, he is using the multibyte support and expects an automatic code
conversion between KOI8-R and UNICODE that is not supported yet.
Not exactly. If you had a look on my first message, you would see that the
problem I see that the
When I try to use postgres 6.5 from a client that
is notlogged on the localhost. I get this :
Connection to database 'mydb'
failed
Unsupported frontend
protocol.
I've seen the same problem in a previous mail but
the error may not come from the postmaster, that is not enough recent because
Maybe you might want to try out MySQL? A little while ago, I compared both
MySQL and PostgreSQL to see how they stacked up (for my purposes, anyway). I
came to the conclusion that while MySQL is a very fast read-only database, it
doesn't support transactions, row-level locks,
At 01:13 PM 14-04-2000 +0800, Thomas wrote:
There has been effort to speed up the vacuuming process, but this isn't the
cure. I believe the fault lies on the optimizer.
For eg, in Bruce Momjian's FAQ 4.9:
PostgreSQL does not automatically maintain statistics. One has to make
an explicit
I have compiled beta5 on linux_sparc...(Sun ULTRA1)
but initdb returns error...
Error: unknown type 'oid8'
...
I compiled with configuration...
--with-template=linux_sparc
--enable-locale
--enable-multibyte=LATIN2
--with-odbc
--with-perl
--with-tcl
What's wrong?
--Greg--
I am developing an Information Management System. I am using
PgAccess(0.98.5) asfront end. The backend is PostgreSQL-6.5.2 and OS is Red
Hat Linux 6.1, onIntel P-II 350 MHz connected with LAN. I have installed
them using RPM ofLinux. I have learned some of the Tcl and Tk for
programming.
Thanks. I will keep you informed of the progress.
Adien
On Wed, 12 Apr 2000 [EMAIL PROTECTED] wrote:
perhaps you'd better first find an evaluation copy of informix, seems that
they have more systematic and well-thought feature set.
there are some historical relations between informix
Ed Loehr wrote:
... it is a well-known "postgresqlism"
that you should consider running vacuum analyze at least nightly, possibly
more frequently. [I run it hourly.]
I think there must be something wrong with the optimiser that it's
"postgresqlism" that you must vacuum analyze
On Fri, 14 Apr 2000, Thomas wrote:
I think there must be something wrong with the optimiser that it's
"postgresqlism" that you must vacuum analyze frequently.
One thing that is not widely known is that vacuum actually has two
orthogonal tasks: garbage collection and statistics collection
At 06:13 AM 4/14/00 -0500, you wrote:
I'd think some how there could be a way to vacuum without having to lock
up the entire DB.
From http://www.postgresql.org/docs/user/sql-vacuum.htm
VACUUM serves two purposes in Postgres as both a means to reclaim
storage and also a means to collect
I am having problems with pgaccess on my X windows. I am using redhat
linux 6.1
postgresql 6.5.2. When I open pgaccess and connect to my databases I
get my list of tables. When I click on any table to open up the data, it
just sits there with that little clock icon. After a long will, it will
Does anyone have any suggestions for a way to keep 2 databases in sync?
Ideally updates need to be made to both... this can't be too uncommon a
requirement. any kind of HA would need it
A. James Lewis ([EMAIL PROTECTED])
- Linux is swift and powerful. Beware its wrath...
Matthew Arnison wrote:
the bloat is a big problem. i just checked it again, and the db has
balloooned to 20 megs again, with i think 2650 unused pages. this is after
vacuuming it last night. i guess we need to setup the vacuum script to run
every hour. i am worried about this locking out
Bruce Momjian wrote:
Ed Loehr wrote:
... it is a well-known "postgresqlism"
that you should consider running vacuum analyze at least nightly, possibly
more frequently. [I run it hourly.]
I think there must be something wrong with the optimiser that it's
"postgresqlism" that
I've been trying to get off this list forever no luck. I thought
I got the damn thing set to nomail, still get mail.
DOES ANYBODY KNOW WHERE I CAN CONTACT A
LIKE PERSON TO GET OFF THIS DAMN LIST?
-Original Message-
From: Peter Eisentraut [SMTP:[EMAIL PROTECTED]]
Sent: Friday,
Andrew Snow wrote:
On Fri, 14 Apr 2000, Thomas wrote:
For large 24x7 installations, it's impossible to vacuum nightly because when
postgresql is vacuuming the table is locked up, to the end-user the database
has already hung.
That's right. I complained about this in a discussion
"Oelkers, Phil" wrote:
I've been trying to get off this list forever no luck.
See instructions at http://www.PostgreSQL.ORG/mhonarc/pgsql-general/
Morning ...
After upgrading the database server to a dual-PIII, 512Meg of RAM,
v7.0beta5 of PostgreSQL *and* cleaning up one of the queries in udmsearch
to get around a cost estimation in PostgreSQL that favor'd a LIKE query,
we think we've *finally* gotten a search engine setup such
For starters I head over to www.postgresql.org
Then I'd probably click on the "Info Central" link and then the "Mailing
lists" link.
From there I'd click on the list that I was subscribed to under "Mailing
List Archives"
Then I'd read the info at the top of the page.
Those pages haven't
21 matches
Mail list logo
