-Original Message-
From: [EMAIL PROTECTED] on behalf of Jonah H. Harris
Sent: Sun 8/27/2006 3:24 AM
To: Joshua D. Drake
Cc: Andrew Dunstan; Bruce Momjian; Tzahi Fadida; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib
It's odd, only 10 people
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED] on behalf of Jonah H. Harris
Sent: Sun 8/27/2006 3:24 AM
To: Joshua D. Drake
Cc: Andrew Dunstan; Bruce Momjian; Tzahi Fadida; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Adding fulldisjunctions to the contrib
It's
Y'know I was gonna check up on that because my recollection was that it was a
2/2 split as well, though I thought that was of people who made their view
clear rather than just -core (whose opinion in this case is no more important
than any of the other long time contributors imho). Don't
There isn't really any need for the second pass in lazy vacuum if the table
has no indexes. The patch seems almost too easy but of course nothing having
to do with vacuum is as easy as it appears. Perhaps there are some gotchas I
haven't thought of?
Index: src/backend/commands/vacuumlazy.c
Jonah H. Harris wrote:
Y'know I was gonna check up on that because my recollection was that
it was a 2/2 split as well, though I thought that was of people who
made their view clear rather than just -core (whose opinion in this
case is no more important than any of the other long time
stark [EMAIL PROTECTED] writes:
There isn't really any need for the second pass in lazy vacuum if the table
has no indexes.
How often does that case come up in the real world, for tables that are
large enough that you'd care about vacuum performance?
regards, tom lane
Tom Lane [EMAIL PROTECTED] writes:
stark [EMAIL PROTECTED] writes:
There isn't really any need for the second pass in lazy vacuum if the table
has no indexes.
How often does that case come up in the real world, for tables that are
large enough that you'd care about vacuum performance?
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
How often does that case come up in the real world, for tables that are
large enough that you'd care about vacuum performance?
I would have had the same objection if it resulted in substantially more
complex code but
Hi,
Quoting Bruce Momjian [EMAIL PROTECTED]:
Great. Please supply documentation and it will be applied. Thanks.
Here it comes, including src+doc patches.
Updated sources according to Michael Fuhr's comments and fixed one FIXME.
Please check documentation patch thoroughly as I'm not native
Joe Conway wrote:
I just received this (offlist), and have not had a chance to review it
myself yet, but figured I should post it now in case others want to have
a look and comment or discuss before feature freeze.
If there are no major objections to the concept, I'll take
responsibility to
When trying to improve the rounding in interval_div and interval_mul,
I came across some behavior that seems counterintuitive to me:
test=# select '1.5 mon'::interval;
interval
-
1 mon 360:00:00
(1 row)
With the time/day/month interval struct introduced in 8.1, I'd expect
Jonah H. Harris wrote:
Y'know I was gonna check up on that because my recollection was that it was
a 2/2 split as well, though I thought that was of people who made their
view clear rather than just -core (whose opinion in this case is no more
important than any of the other long time
On Sat, Jul 29, 2006 at 09:14:16PM -0400, Greg Sabino Mullane wrote:
Today on IRC David Fetter and some others were discussing version
numbers and we realized that although libpq now provides the version of
Postgres as a number, this is still a wheel that is being reinvented by
apps many times
Hi,
I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.
This is needed because ecpg_config.h ends up in the build dir rather
than the source dir.
Thanks,
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The
Alvaro Herrera wrote:
I just detected another problem with building ecpg in a VPATH
environment. This patch fixes it for me.
I think you will find that $(top_builddir)/$(subdir) is equivalent
to .
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end
Removed Cc: to pgsql-hackers.
Zoltán,
Zoltan Boszormenyi wrote:
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.
Thanks.
Alvaro Herrera [EMAIL PROTECTED] writes:
... I'd do it myself but I'm heading to bed right now.
...
I'll repost a reworked version at some point, if no one beats me to it.
I was planning to start looking at this patch tomorrow (unless Gavin
produces a new bitmap-index patch by then). I'll
Hello
This patch allows using any row expression in return statement and does
transformation from untyped row to composite types if it's necessary.
Regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli?
18 matches
Mail list logo