Rahul Ravindrudu wrote:
>
>Hi,
> I have downloaded the postgres version 6.5.3 . My m/c is redhat linux 6.0
>.
> Postgres compiles without any error. I then initialize the database using
> initdb. But when i start the postmaster i get the following error message
>.
>
Hi,
I had posted a message yesterday on 4 things which bugged me about postgres
while running a 24x7 app.
This discussion has degenrated into a discussion on vacuum.
Now here is a person (Michael), who wants help to decide whether postgres is
the right choice or not. It would be nice to help him.
Hi,
I have downloaded the postgres version 6.5.3 . My m/c is redhat linux 6.0.
Postgres compiles without any error. I then initialize the database using
initdb. But when i start the postmaster i get the following error message.
Database system in directory /tmp/pgsql/data is not compat
> While on the subject of vacuum. I wonder if
> Tom's time will be better utilized at figuring out how to
> get rid of vacuum all together rather than trying to fix
> it. Simply have that functionality replaced with a more
> modern way of data management and query optimization.
> That command was
While on the subject of vacuum. I wonder if
Tom's time will be better utilized at figuring out how to
get rid of vacuum all together rather than trying to fix
it. Simply have that functionality replaced with a more
modern way of data management and query optimization.
That command was nothing but
On Thu, 6 Jan 2000, Culberson, Philip wrote:
This is a considerable amount faster. I never thought about the
indices getting hit here. Thanks a lot.
# In his very insightful post last week, Mike Mascari pointed out that, on
# tables with heavy insert/updates, it was much faster to drop
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 06, 2000 5:15 PM
I'm using the fti function that is included with the source, and seem to
have run into a problem with the trigger call.
I have a full text index with only around 556645 entries
On Thu, 6 Jan 2000, Ed Loehr wrote:
> I said: "There aren't any results for pgsql..."
>
> The Hermit Hacker wrote:
>
> > ... and the database is just being populated right now, and ...
>
> D'oh!!! Read more carefully! My apologies for the brain-dead spam...
ya, still playing with things..
In his very insightful post last week, Mike Mascari pointed out that, on
tables with heavy insert/updates, it was much faster to drop the index,
vacuum analyze, and then rebuild the index. Maybe in vacuum there is a
specific inefficiency in what Mike coined "defragment"ing indexes.
[Snip]
8. No
I said: "There aren't any results for pgsql..."
The Hermit Hacker wrote:
> ... and the database is just being populated right now, and ...
D'oh!!! Read more carefully! My apologies for the brain-dead spam...
Ed Loehr wrote:
> The Hermit Hacker wrote:
>
> > Well, we've finally gotten what seems to be a working version of this
> > going, and, so far, I'm quite impressed...
> >
> > If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
> > can see it in action.
>
> Site-wide search f
The Hermit Hacker wrote:
> Well, we've finally gotten what seems to be a working version of this
> going, and, so far, I'm quite impressed...
>
> If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
> can see it in action.
Site-wide search for pgsql yielded no results momen
> Untrue, vacuum is *extremely* important for updating statistics.
> If you have a lot of data in a table, and you have never vacuumed, you
> might as well not have any indices. It'd be nice if you could seperate
> the stat update from the storage reclaim. Actually, it'd be nice if you
> c
On Thu, 6 Jan 2000, The Hermit Hacker wrote:
# Okay, my understanding is that a vacuum does a 'cleanup', while a vacuum
# analyze does a cleanup *and* stats...
That may be correct, but the stats without a cleanup would be a
nice option. :) That would give me the ability to update my s
On Thu, 6 Jan 2000, Dustin Sallings wrote:
> Untrue, vacuum is *extremely* important for updating statistics.
> If you have a lot of data in a table, and you have never vacuumed, you
> might as well not have any indices. It'd be nice if you could seperate
> the stat update from the storage
On Thu, 6 Jan 2000, The Hermit Hacker wrote:
# > d) Postgres manual recommends a nightly vacuum. I read this also a bit
# > late. This is equivalent of rebuild database. While this is in
# > progress all other clients wait for vacuum release locks. This is
# > really a handicap for a 24x7 app.
#
On Thu, 6 Jan 2000, Guillaume Rousse wrote:
> Subsidiary question : why is mySQL excluded from RDBMS comparison on postgress
> www site ?
beceause it doesn't support key features in an RDBMS, namely transactions,
and, wiht transcations, rollbacks...
On Thu, 6 Jan 2000, Oleg Broytmann wrote:
> On Thu, 6 Jan 2000, The Hermit Hacker wrote:
> > So far, from what i've seen, its a nice tool ... I like the fact that
> > there is no such thing as "Search downtime", since the indexer can run
> > while ppl are seaching. With ht/Dig, while it was inde
On Thu, 6 Jan 2000, The Hermit Hacker wrote:
> So far, from what i've seen, its a nice tool ... I like the fact that
> there is no such thing as "Search downtime", since the indexer can run
> while ppl are seaching. With ht/Dig, while it was indexing, the databases
> were down and you couldn't se
Well, we've finally gotten what seems to be a working version of this
going, and, so far, I'm quite impressed...
If you go to http://www.postgresql.org/cgi/search.cgi (URL to change), you
can see it in action.
The WebMaster still has to do formatting work on it, and link it into the
main site,
I have a PostgreSQL 6.4.2 database running on SuSE Linux 6.1
I am trying to get a Large Object using the JDBC driver extensions for
large objects. When I call the read method it reads the data correctly,
but it closes the backend, so all the client connections to the server are
broken.
I tried us
Dear Dark:
If you do a '\l', do you see your database? Are you connected
to it? (if not, use \connect ...).
Probably not it, but it's worth checking the obvious first.
-frank
On Thu, 6 Jan 2000, Dark-Emperor wrote:
> i have created a database with one table to
Hi.
Some questions on object-orientation of Postgress:
Firstly, is there any possibility of using directly a class name as a type for
another class attribute, without using an explicit key linking, as in a full
ODBMS ?
For example :
CREATE writers(name TEXT)
CREATE books(authors writers[])
Secondl
On Thu, 6 Jan 2000, Differentiated Software Solutions Pvt. Ltd. wrote:
> b) There are quite a few things which you'd take for granted in other DBs
> which postgres does not have. Quite late in the day I was shocked to find
> that postgres does not have roll-forward transaction logging. They have
Hi,
It was good that I have chanced upon your mail.
I'm currently implementing a very high performance reliability application
using postgres.
I'm risking lots of debate and criticism on what I have to say. This is
based on practical experience. I have decent experience is using DB2 and a
reason
25 matches
Mail list logo
