Bruce Momjian wrote:
Simon Riggs wrote:
Please lets be real about this and allow the abbreviations suggested.
Agreed.
Your efforts to introduce units is excellent and much appreciated by
all; please don't make them harder to use than the plain numbers were.
Agreed.
Agreed. I don't see
Michael Paesold wrote:
It's not about a certain standard. There are so many different ways in
the world to write time units, so in a certain context a standard is
really useful to constrain the format/syntax, but...
This all was about usability of a configuration file, wasn't it? Now,
Peter,
Dave Page wrote:
Michael Paesold wrote:
It's not about a certain standard. There are so many different ways in
the world to write time units, so in a certain context a standard is
really useful to constrain the format/syntax, but...
This all was about usability of a configuration file,
On Wed, 20 Jun 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
On Wed, 20 Jun 2007, Bruce Momjian wrote:
Comments to editorial work of Bruce Momjian.
fulltext-intro.sgml:
it is useful to have a predefined list of lexemes.
Bruce, here should be list of types of lexemes !
Agreed. Are the
Heikki Linnakangas [EMAIL PROTECTED] writes:
My 2c on this:
The way I was taught in school is that min is for minute and mon is for
month. Specifically, not m.
Sure, but nobody's saying you shouldn't be able to use min. If you think
using m is wrong then by all means institute a policy at
On Wed, 20 Jun 2007, Bruce Momjian wrote:
We need to decide if we need oids as user-visible argument. I don't see
any value, probably Teodor think other way.
This is a good time to clean up the API because there are going to be
user-visible changes anyway.
Bruce, just remove oid argument
Andrew Sullivan wrote:
On Wed, Jun 20, 2007 at 12:34:21PM -0400, Robert Treat wrote:
FWIW pg_migrator is a pretty good swing at an in-place upgrade tool for
8.1-8.2. Unfortunately until the PGDG decides that in-place upgrade is a
constraint their willing to place on development, I see them a
Since we're discussing upgrades, let me summarize the discussions we had
over dinner in Ottawa for the benefit of all:
* pg_migrator is a sound approach to handling catalog changes.
* Handling any page format change that doesn't grow the space taken by
data is straightforward. Note that all
Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is confusing.
To whom? the person writing it?
If everyone around here had gotten their way we'd
Peter Eisentraut wrote:
Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is confusing.
To whom? the person writing it?
If everyone
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is confusing.
To whom? the person writing it?
If
Peter Eisentraut wrote:
Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway
signage, 5m means five miles. Even the Americans do that better.
Yeah, but you know *exactly* what it means :-p
Regards, Dave
---(end of broadcast)---
Gregory Stark wrote:
Dave Page [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Btw.: I'm currently at DebConf in Edinburgh. On Scottish motorway signage,
5m means five miles. Even the Americans do that better.
Yeah, but you know *exactly* what it means :-p
Well the good news is that
Peter Eisentraut wrote:
If everyone around here had gotten their way we'd already be in a situation
were you could write
log_rotation_age = 5m
log_rotation_size = 5m
And someone trained in the metric system would think, What, five meters?.
So it rotates when age and size are the same or
On 6/21/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is confusing.
To whom? the person writing it?
Marko Kreen wrote:
Considering Postgres will never user either meter or mile
in settings, I don't consider your argument valid.
I don't see the value of having units globally unique (literally).
It's enough if they unique in the context of postgresql.conf.
Thus +1 of having additional
On 6/21/07, Michael Paesold [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
Considering Postgres will never user either meter or mile
in settings, I don't consider your argument valid.
I don't see the value of having units globally unique (literally).
It's enough if they unique in the context
Peter Eisentraut wrote:
Am Donnerstag, 21. Juni 2007 00:38 schrieb Gregory Stark:
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is confusing.
To whom? the person writing it?
If everyone around here had
Marko Kreen wrote:
On 6/21/07, Michael Paesold [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
Considering Postgres will never user either meter or mile
in settings, I don't consider your argument valid.
I don't see the value of having units globally unique (literally).
It's enough if they
Am Donnerstag, 21. Juni 2007 00:10 schrieb Gregory Stark:
Afaict nobody has expressed a single downside to accepting other
abbreviations.
The two downsides I can see are that it would confuse users (even if it
apparently wouldn't confuse *you*), and that there is a chance that the
Am Donnerstag, 21. Juni 2007 15:12 schrieb Andrew Dunstan:
You don't seem to have any understanding that the units should be
interpreted in context.
You are right. I definitely have an understanding that units must be
interpretable without context. And that clearly works for the most part.
On Jun 19, 2:23 pm, [EMAIL PROTECTED] (Josh Berkus) wrote:
Tim,
I have two types of tables, for sake of argument lets call it these:
1) product 10,000,000 rows
2) product_activity 1,000,000,000 rows
pgsql-performance is the correct list for your question. Please
On Thu, Jun 21, 2007 at 03:24:51PM +0200, Michael Paesold wrote:
There are valid reasons against 5m as mega-bytes, because here m does
not refer to a unit, it refers to a quantifier (if that is a reasonable
English word) of a unit. So it should really be 5mb.
log_rotation_age = 5m
Andrew Sullivan [EMAIL PROTECTED] writes:
Nevertheless, I think that Tom's original suggestion was at least a
HINT, which seems perfectly reasonable to me.
That's the only idea in the whole thread that hasn't been objected to,
so let's just do that and have done with it. (Even if we were to
On Thu, Jun 21, 2007 at 11:55:56AM -0400, Tom Lane wrote:
where the HINT gets appended if there's something after the integer but
it doesn't look like any of the allowed units. Objections?
Sounds like a good idea to me.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
The very definition of news
http://www.sigaev.ru/misc/tsearch_core-0.52.gz
Plan was:
1) rename FULLTEXT to TEXT SEARCH in SQL command
done
2) rework Snowball stemmer's as Tom suggested
done
3) ALTER FULLTEXT CONFIGURATION cfgname ADD/ALTER/DROP MAPPING
done
4) remove support of default configuration per scheme. Default
On Thursday 21 June 2007 08:34, Andrew Sullivan wrote:
On Thu, Jun 21, 2007 at 03:24:51PM +0200, Michael Paesold wrote:
There are valid reasons against 5m as mega-bytes, because here m does
not refer to a unit, it refers to a quantifier (if that is a reasonable
English word) of a unit. So
Heikki Linnakangas [EMAIL PROTECTED] writes:
* Page format changes that grow data size are problematic, because there
can be pages that can't be expanded to the new format because there's
not enough space. However, it would be possible to write a pre-upgrade
program to look for the
Ühel kenal päeval, N, 2007-06-21 kell 21:44, kirjutas Teodor Sigaev:
http://www.sigaev.ru/misc/tsearch_core-0.52.gz
Plan was:
1) rename FULLTEXT to TEXT SEARCH in SQL command
done
2) rework Snowball stemmer's as Tom suggested
done
3) ALTER FULLTEXT CONFIGURATION cfgname
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, N, 2007-06-21 kell 21:44, kirjutas Teodor Sigaev:
6) use encoding names instead of locale's names in configuration
Ugh. I missed that knowledge of encoding doesn't allow to determine exact
language
most languages can be written
I've been reflecting a bit about whether the notion of deferred fsync
for transaction commits is really safe. The proposed patch tries to
ensure that no consequences of a committed transaction can reach disk
before the commit WAL record is fsync'd, but ISTM there are potential
holes in what it's
I finally was able PL/R to compile and run on Windows recently. This has
lead to people using a Windows based client (typically PgAdmin III) to
create PL/R functions. Immediately I started to receive reports of
failures that turned out to be due to the carriage return (\r) used in
standard
Joe Conway [EMAIL PROTECTED] writes:
I finally was able PL/R to compile and run on Windows recently. This has
lead to people using a Windows based client (typically PgAdmin III) to
create PL/R functions. Immediately I started to receive reports of
failures that turned out to be due to the
Joe Conway wrote:
I finally was able PL/R to compile and run on Windows recently. This
has lead to people using a Windows based client (typically PgAdmin
III) to create PL/R functions. Immediately I started to receive
reports of failures that turned out to be due to the carriage return
(\r)
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
My first thought on fixing this issue was to simply replace all
instances of '\r' in pg_proc.prosrc with '\n' prior to sending it to the
R parser. As far as I know, any instances of '\r' embedded in a
syntactically valid R statement must be
Jaime Casanova wrote:
note the month abreviation (mons?) is this intentional?
This notation has been used since the code was written (~7 years ago) [1].
[1]
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/datetime.c?rev=1.42;content-type=text%2Fx-cvsweb-markup
--
I wrote:
I found that the autovacuum launcher continues to run and spawn workers
after reloading the configuration file with autovacuum = off in CVS HEAD.
Sorry, I found this issue will be fixed in the 'more autovacuum fixes' patch.
The workers still continues to run, but it would be not a
I wrote:
the runtime statistics are not invalidated -- it cound be a bug.
pgstat_drop_relation() is expecting relid (pg_class.oid) as the argument,
but we pass it relfilenode.
[storage/smgr/smgr.c]
smgr_internal_unlink(RelFileNode rnode, int which, bool isTemp, bool isRedo)
38 matches
Mail list logo
