Bruce Momjian wrote:
> I have implemented your ideas for checking BLCKSZ >= 1024,
I think the check should be were the issue arises, not in some distant
file without explanation.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)-
On Thu, 22 Feb 2007, FAST PostgreSQL wrote:
As we are triggering the sql output in log_destination, if the user
gives 'syslog,sql' as options he is going to get two different looking
logs (in terms of contents) depending upon his settings.
Yes, exactly; it's a good thing. People add and remo
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > >
> > > I applied the optional VACUUM FULL version, but modified to code to say
> > > 20% rather than a factor of 5, attached.
> >
> > String construction does not work well with translations; please
> > reformulate this.
>
Hi all,
Here is my preliminary work on porting pg_trgm to GIN. pg_trgm can be
a very good addition to tsearch2 to suggest spellings for mispelled
words as explained in the README.pg_trgm file and I'd like to use it
in this case. GIST implementation is a bit slow so I tried to port it
to use GIN.
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > I applied the optional VACUUM FULL version, but modified to code to say
> > 20% rather than a factor of 5, attached.
>
> String construction does not work well with translations; please
> reformulate this.
>
> > +er
On Thu, Feb 22, 2007 at 11:50:06AM +1100, FAST PostgreSQL wrote:
> - The log output will be in COPY format and will include the following
> information, irrespective of the log_line_prefix setting.
> ( timestamp_with_milliseconds, timestamp, username, databasename,
> sessionid, host_and_port,
Bruce Momjian wrote:
>
> I applied the optional VACUUM FULL version, but modified to code to say
> 20% rather than a factor of 5, attached.
String construction does not work well with translations; please
reformulate this.
> + errhint("Consider%sincreasing the
> con
I applied the optional VACUUM FULL version, but modified to code to say
20% rather than a factor of 5, attached.
---
Simon Riggs wrote:
> On Mon, 2007-02-05 at 11:55 +, Simon Riggs wrote:
> > On Sat, 2007-02-03 at 22:11
Patch applied. Thanks.
---
Heikki Linnakangas wrote:
> Tom Lane wrote:
> > While testing it I realized that there seems to be a nearby bug in
> > _bt_findsplitloc: it fails to consider the possibility of moving all the
> >
On Tue, 2007-02-20 at 09:48 +0200, Hannu Krosing wrote:
> I'm not sure about the "we are more concerned about the large tables"
> part. I see it more as a device for high-update tables. This may not
> always be the same as "large", so there should be some fallbacks for
> case where you can't get t
I am putting this in the patches queue so it is not lost. I believe
Neil is working applying this.
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 revie
> Applied.
Thanks for your help Bruce (and Tom and Nikhil).
-- Korry
Applied.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > > + CFLAGS="$CFLAGS -DPROFILE_PID_DIR -pg ${PROFILE_CFLAGS}"
> >
> > Kindly use AC_DEFINE instead of random -D i
Bruce Momjian wrote:
Updated version applied. I reduced the numering changes for the macros.
There was also documentation text for "dow" and a few others that said
"(for timestamp values only)", but in fact the field worked
for "timestamptz" and "date" too, so I removed the mentions. If people
14 matches
Mail list logo
