* Magnus Naeslund(f) [EMAIL PROTECTED] [010426 21:17] wrote:
How does 7.1 work now with the vacuum and all?
Does it go for indexes by default, even when i haven't run a vacuum at all?
Does vacuum lock up postgres? It says the analyze part shouldn't, but how's
that for all of the vacuum?
At 08:39 AM 26-04-2001 -0400, mlw wrote:
I am getting a bit concerned about Postgres 7.1 performance with multiple
connections. Postgres does not seem to scaling very well. Below there is a
list
of outputs from pgbench with different number of clients, you will see that
My postmaster start line
If you are familiar with cddb (actually freedb.org) I am taking that data in
putting it into postgres. The steps are: (pseudo code)
select nextval('cdid_seq');
begin;
insert into titles (...) values (...);
for(i=0; i tracks; i++)
insert into tracks (...) values (...);
Hiroshi Inoue [EMAIL PROTECTED] writes:
There's a report of startup recovery failure in Japan.
DEBUG: redo done at (1, 3923880100)
FATAL 2: XLogFlush: request is not satisfied
postmaster: Startup proc 4228 exited with status 512 - abort
Is this person using 7.1 release, or a beta/RC
Alfred Perlstein wrote:
* Magnus Naeslund(f) [EMAIL PROTECTED] [010426 21:17] wrote:
How does 7.1 work now with the vacuum and all?
Does it go for indexes by default, even when i haven't run a vacuum at all?
Does vacuum lock up postgres? It says the analyze part shouldn't, but how's
* mlw [EMAIL PROTECTED] [010427 05:50] wrote:
Alfred Perlstein wrote:
* Magnus Naeslund(f) [EMAIL PROTECTED] [010426 21:17] wrote:
How does 7.1 work now with the vacuum and all?
Does it go for indexes by default, even when i haven't run a vacuum at all?
Does vacuum lock up
What's the deal with vacuum lazy in 7.1? I was looking forward to it. It was
never clear whether or not you guys decided to put it in.
If it is in as a feature, how does one use it?
If it is a patch, how does one get it?
If you actually download and read the enclosed READMEs it's
Sorry for the delay in the response. It took be a day to get
everything upgraded to 7.1. To restate the problem - in 7.0 with
GEQO enabled, a 15-way join took 10 seconds. With GEQO disabled it
took 18 seconds. 7.1 out of the box took only 2 seconds! I was amazed
and shocked at this damned
Hi,
Firstly, the attached patch implements archiving of off-
line redo logs, via the wal_archive_dir GUC option. It
builds and appears to work (though it looks like guc-file.l
has some problems with unquoted strings containing slashes).
TODO: handle EXDEV from link/rename, and copy rather
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
Searching software ...
If you go to fts.postgresql.org, it is like night-day as far as
the old searching is concerned ...
On Fri, 27 Apr 2001, The Hermit Hacker wrote:
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
Searching software ...
If you go to fts.postgresql.org, it is like night-day as far
There's a report of startup recovery failure in Japan.
DEBUG: redo done at (1, 3923880100)
FATAL 2: XLogFlush: request is not satisfied
postmaster: Startup proc 4228 exited with status 512 - abort
Is this person using 7.1 release, or a beta/RC version? That looks
just like the
On Fri, 27 Apr 2001, The Hermit Hacker wrote:
Actually, default appears to be the last month worth of messages ... check
your date range :)
I did, I just find it hard to believe that *you* of all people were
that quiet! I did some other searches since then for things like 7.1
where I knew
Actually, default appears to be the last month worth of messages ... check
your date range :)
On Fri, 27 Apr 2001, Vince Vielhaber wrote:
On Fri, 27 Apr 2001, The Hermit Hacker wrote:
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his
On Fri, 27 Apr 2001, Vince Vielhaber wrote:
It *is* alot quicker. I did a search for scrappy on All Lists and
it came back in 0.151 secs. But it only found 104 matches, have you
been that quiet Marc?
I got 3604 messages for the period from 1995 to now.
On Fri, 27 Apr 2001, The Hermit Hacker wrote:
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
All work was done by Teodor Sigaev ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED])
as
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ... now searching is a useful function :)
And
You can thank Tom Lane for most/all of our optimization improvements.
Sorry for the delay in the response. It took be a day to get
everything upgraded to 7.1. To restate the problem - in 7.0 with
GEQO enabled, a 15-way join took 10 seconds. With GEQO disabled it
took 18 seconds. 7.1 out
On Fri, 27 Apr 2001, Bruce Momjian wrote:
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ... now
On Fri, 27 Apr 2001, Bruce Momjian wrote:
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ...
We have discussed splitting the tree on May 1 to start 7.2 development.
If no one objects, we will stay with that schedule.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830
On Fri, 27 Apr 2001, Bruce Momjian wrote:
On Fri, 27 Apr 2001, Bruce Momjian wrote:
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and
What's the deal with vacuum lazy in 7.1? I was looking
forward to it. It was never clear whether or not you guys
decided to put it in.
If it is in as a feature, how does one use it?
If it is a patch, how does one get it?
If it is neither a patch nor an existing feature, has
development
WAL was a difficult feature to add to 7.1. Currently, it is only used
as a performance benefit, but I expect it will be used in the future to
add new features like:
Advanced Replication
Point-in-time recovery
Row reuse without vacuum
--
Bruce Momjian
`make depend' is broken in the CVS sources. I've only tested it when
using a build directory which is different from the source directory,
but frankly it looks broken anyhow.
This is what I get:
make -C backend depend
make[1]: Entering directory `/home/ian/pgsql-objdir/src/backend'
for i in
Ian Lance Taylor writes:
`make depend' is broken in the CVS sources.
'make depend' doesn't exist anymore. Use configure --enable-depend.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP
WAL was a difficult feature to add to 7.1. Currently, it is only used
as a performance benefit, but I expect it will be used in the future to
Not only. Did you forget about btree stability?
Partial disk writes?
add new features like:
Advanced Replication
I'm for sure not fan of
I'm trying to use pg_dump to backup my tables one at a time from
Postgres 7.0.3 (I'll upgrade to 7.1 in a few weeks). I'm getting a
strange error that I've never encountered before.
The backup call is:pg_dump db01 -t cell | gzip cell.backup.gz
The error is : failed sanity check, table
On Fri, 27 Apr 2001, Bruce Momjian wrote:
We have discussed splitting the tree on May 1 to start 7.2 development.
If no one objects, we will stay with that schedule.
Please see other thread where we are actually discussing this ... if you
have anything to add to that thread please do so ...
On Fri, 27 Apr 2001, Mikheev, Vadim wrote:
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
Same question as I asked Bruce ... how? :) I wasn't trying to be
fascisious(sp?) when I asked, I didn't realize the two were connected and
am curious as to how :)
On Fri, 27 Apr 2001, Bruce Momjian wrote:
How?
I guess other hosts could read the WAL to find out what changed.
I wonder if that would get around one of the issues I had brought up a
ways back concerning replication and stuff like sequences ...
Row reuse without vacuum
How?
On Fri, 27 Apr 2001, Bruce Momjian wrote:
How?
I guess other hosts could read the WAL to find out what changed.
I wonder if that would get around one of the issues I had brought up a
ways back concerning replication and stuff like sequences ...
Yep, WAL collects all database
On Fri, 27 Apr 2001, Mikheev, Vadim wrote:
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
Same question as I asked Bruce ... how? :) I wasn't trying to be
fascisious(sp?) when I asked, I didn't realize the two were
connected and am curious as to
Yep, WAL collects all database changes into one file. Easy to see how
some other host trying to replication a different host would find the
WAL contents valuable.
Unfortunately, slave database(s) should be on the same platform
(hardware+OS) to be able to use information about *physical*
[ Charset ISO-8859-1 unsupported, converting... ]
Yep, WAL collects all database changes into one file. Easy to see how
some other host trying to replication a different host would find the
WAL contents valuable.
Unfortunately, slave database(s) should be on the same platform
Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.
... reasonable
On Fri, 27 Apr 2001, Brook Milligan wrote:
Over the past few months there've been a number of requests for an
interactive type documentation setup like the folks at php.net have.
Great to add to the documentation, but I hope the PostgreSQL project
doesn't take it so far as to make the
Over the past few months there've been a number of requests for an
interactive type documentation setup like the folks at php.net have.
The first version of it is now online and ready for testing. You can
also search the docs, but the search isn't that exotic - but since
there are fewer than
As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
Marc G.
As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...
Does anyone have any outstanding fixes for v7.1.x that they
want to see in *before* we do this release? Any points unresolved
that anyone knows about that we need to look at?
Hiroshi
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
Is there a list of what IS getting changed? Can this be posted somewhere
or is the changelist enough?
- Brandon
The Hermit Hacker wrote:
As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92
At 03:44 PM 27-04-2001 -0300, The Hermit Hacker wrote:
On Fri, 27 Apr 2001, Bruce Momjian wrote:
On Fri, 27 Apr 2001, Bruce Momjian wrote:
Huh? *raised eyebrow* This is a standalone application that they've
donated to the project ... nothing that can be added to any of our
featurerequest
Well if stuff like that ends up in Postgresql would it be possible to index
LIKE '%xxx%' searches? That way all people have to do is create the
relevant index and use a fts_ops or something, and voila LIKE '%xxx%'
searches become faster, with maybe some performance+disk space
... 7.1 out of the box took only 2 seconds! I was amazed
and shocked at this damned impressive improvement in planning
speeduntil I actually used the explicit JOIN syntax described in
11.2. Instanteous results! Instantaneous.
But it is possible, under many circumstances, for query
This patch adds support for %TYPE in CREATE FUNCTION argument and
return types.
%TYPE is already supported by PL/pgSQL when declaring variables.
However, that does not help with the argument and return types in
CREATE FUNCTION.
Using %TYPE makes it easier to write a function which is
What would be nice, and I don't know how it would be done or what the
syntax would be, would be a feature that allows PostgreSQL to skip
not only the parsing stage, but the planning stage as well. Then,
when the data has changed dramatically enough to warrant it, as you
point out, a command
48 matches
Mail list logo
