Hi,
Simon Riggs [EMAIL PROTECTED] writes:
Group commit is a well-documented technique for improving performance,
The issue here is not is group commit a good idea in the abstract?.
It is is the commit_delay implementation of the idea worth a dime?
... and the evidence we have all points
Marc G. Fournier wrote:
Pick your version:
# ls -lt /usr/local/bin/autoconf*
-r-xr-xr-x 1 root wheel 7672 Aug 22 2004
/usr/local/bin/autoconf259 -r-xr-xr-x 1 root wheel 6194 Aug 22
2004 /usr/local/bin/autoconf253 -rwxr-xr-x 1 root wheel 5007 Jul
27 2003
Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label
has only informational value, but can enhance readability large block and
enhance likeness with Oracle.
Reviewed and applied -- thanks for the patch.
-Neil
---(end of
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with PGSQL's
Gist API,
I would do the job.
Regards,
Janko Richter
---(end of broadcast)---
Janko Richter wrote:
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with
PGSQL's Gist API,
I would do the job.
I don't think anyone is working in improving it, no.
--
Bruce Momjian
Bruce Momjian wrote:
Janko Richter wrote:
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with PGSQL's
Gist API,
I would do the job.
I don't think anyone is working in improving it, no.
OK.
Janko Richter [EMAIL PROTECTED] writes:
OK. If I start developing now, is there a chance to put it in 8.1 or is it
better to do it for 8.2. I'm not sure about feature freezing of 8.1.
Feature freeze for 8.1 is on Monday.
regards, tom lane
Janko Richter [EMAIL PROTECTED] writes:
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with
PGSQL's Gist API,
I would do the job.
What changes have you got in mind exactly?
Janko Richter wrote:
Bruce Momjian wrote:
Janko Richter wrote:
Is currently anybody working on extending rtree_gist? I have seen, it is
moved
to core now. I had a look at it and because I have some experience with
PGSQL's Gist API,
I would do the job.
I don't think
Tom Lane wrote:
Janko Richter [EMAIL PROTECTED] writes:
Is currently anybody working on extending rtree_gist? I have seen, it is moved
to core now. I had a look at it and because I have some experience with PGSQL's
Gist API,
I would do the job.
What changes have you got in mind exactly?
Janko Richter [EMAIL PROTECTED] writes:
Tom Lane wrote:
What changes have you got in mind exactly?
At first, I would implement all RTREE supported operators in GIST.
Then, the GIST implementation may be a full replacement/alternative for RTREE.
That's already done.
Futhermore, I would
Tom Lane wrote:
(The TODO item as written is pretty much a dead letter anyway: nobody
is going to do any more work on rtree. It should probably read add
more gist index support for geometric data types.)
TODO updated.
--
Bruce Momjian| http://candle.pha.pa.us
Tom Lane wrote:
I'm not sure that you want to think of this as a direct copy of what
rtree would do. The set of interesting operators isn't really the same
for all these types ... which was hard or impossible to support in rtree
but is trivial in GIST. As an example, contains/contained in are
It certainly helps if you need to debug a process.
Ken
On Fri, Jul 01, 2005 at 09:06:03PM +0300, Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support
Greg Stark wrote:
Just as a bit of supporting anecdotal evidence. I ended up storing longitude
and latitude redundantly in my tables as a point and also as a 0-area box just
so I could use the box contains box operator because there's no box
contains point operator.
If necessary, I will add
'k, just checked, and we have the FreeBSD one installed, and always have
used in the in the past ... I can install the gnu-* one if you think it
will make a difference though, but I don't believe we've had any problem
reports on any of our past releases ... ?
On Sat, 2 Jul 2005, Peter
Marc G. Fournier wrote:
'k, just checked, and we have the FreeBSD one installed, and always
have used in the in the past ... I can install the gnu-* one if you
think it will make a difference though, but I don't believe we've had
any problem reports on any of our past releases ... ?
I think
Peter Eisentraut wrote:
Marc G. Fournier wrote:
'k, just checked, and we have the FreeBSD one installed, and always
have used in the in the past ... I can install the gnu-* one if you
think it will make a difference though, but I don't believe we've had
any problem reports on any of our
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
gnu-autoconf with the note This port is specifically designed for
developers that want to create cross-platform software distributions on
Christopher Kings-Lynne wrote:
I think the whole GiST limitations page can be removed now...
http://developer.postgresql.org/docs/postgres/limitations.html
Done.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+
These patches will require some refactoring and documentation, but I
will do that when I apply it.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers
Is a new version of this patch coming?
---
Bruce Momjian wrote:
Dave Page wrote:
-Original Message- From: Bruce Momjian
[mailto:[EMAIL PROTECTED] Sent: Wed 6/29/2005 2:16 AM To: Dave
Page Cc:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Is a new version of this patch coming?
Yup, attached. Per
On Sat, 2 Jul 2005, Peter Eisentraut wrote:
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
gnu-autoconf with the note This port is specifically designed for
developers that want to create
Marc G. Fournier wrote:
On Sat, 2 Jul 2005, Peter Eisentraut wrote:
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
gnu-autoconf with the note This port is specifically designed for
Andrew Dunstan [EMAIL PROTECTED] writes:
Marc G. Fournier wrote:
If it did produce different output, why haven't we noticed it prior to
this? Has there actually *been* a problem that nobody has reported?
Is autoconf actually run as part of any of our packaging scripts?
I don't think so
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Is a new version of this patch coming?
Yup,
Patch applied. Thanks.
---
Jim C. Nasby wrote:
On Tue, Jun 28, 2005 at 02:28:11PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
All the logs for the most recent run against HEAD are now at
Andreas Pflug wrote:
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Is a new
I realize this needs review, but I will put it the queue so we don't
forget it.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
On Sat, 2 Jul 2005, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Sat, 2 Jul 2005, Peter Eisentraut wrote:
Bruce Momjian wrote:
Does the FreeBSD one actually produce different output?
If it did not, why would they bother making a separate package called
gnu-autoconf with the note
Bruce Momjian wrote:
Peter Eisentraut wrote:
Does the FreeBSD one actually produce different output? I don't
remember seeing any of that and I am not running FreeBSD.
On my 5.4 system autoconf259 and gnu-autoconf both fetch the *same* src
file (autoconf-2.59.tar.bz2 with md5sum
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Uh, what exactly did you cut out? I suggested dropping the dumping of
full page images, but not removing CRCs altogether ...
Attached is the patch I used.
OK, thanks for the clarification. So it does seem that dumping full
page
On Jul 3, 2005, at 8:35 AM, Bruce Momjian wrote:
Andreas Pflug wrote:
Dave Page wrote:
Yup, attached. Per our earlier conversation, pg_dbfile_size() now
returns the size of a table or index, and pg_relation_size()
returns the
total size of a relation and all associated indexes and toast
I've noticed that contrib/pgcrypto/pgcrypto.sql.in doesn't include
a volatility category in its CREATE FUNCTION statements, so the
functions are all created VOLATILE. Shouldn't most of them be
IMMUTABLE? Or do the algorithms have side effects? So far I've
found no discussion about this except
Bruce Momjian wrote:
I realize this needs review, but I will put it the queue so we don't
forget it.
The patch does not need review, as it doesn't even attempt to fix the
problem. (I just wrote the patch while analyzing the problem to make the
error condition more easily reproduceable). I
Marc G. Fournier wrote:
If it did produce different output, why haven't we noticed it prior
to this? Has there actually *been* a problem that nobody has
reported?
Note that we have never used Autoconf 2.59 before, so nobody could have
ever noticed and reported anything. This FreeBSD vs. GNU
37 matches
Mail list logo
