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 ca
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 independent
(Haven't seen this mentioned on-list yet)
I saw a report that Informix was selling its database business to IBM
for ~US$1B. Which would have IBM owning the remnants of Illustra, which
was based on University Postgres. Confirmation of the sale is at
www.informix.com :(
On a possibly related note,
> ... 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
>
> 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 hit for
>
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
> 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
[ 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
> (
> 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*
ch
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
> 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
> > > 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 :)
After implementing UNDO operation (we
> 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 data
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
> >
> > H
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:
>
> >
> > 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
>
> How?
I guess other hosts could
On Fri, 27 Apr 2001, Bruce Momjian wrote:
>
> 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
How?
> Point-in-time recovery
I thought t
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 ..
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 ro_
> 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 o
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
`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 acc
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
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
> 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
> develo
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 t
>
> 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
> 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?
Hi
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 ...
> > > >
> > > > *Ma
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 Bly
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. Fo
> 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
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 communi
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
> 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
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 re
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 500
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.
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
> > Ol
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
> > 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
> j
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->da
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 ...
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
than
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 imp
> > 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 READ
* 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
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, b
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
> 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 (.
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 l
51 matches
Mail list logo
