On 20 Sep 2002 at 18:41, Nigel J. Andrews wrote:
On Fri, 20 Sep 2002, Shridhar Daithankar wrote:
In select test where approx. 15 rows where reported with query on index field,
mysql took 14 sec. and psotgresql took 17.5 sec. Not bad but other issues
eclipse the result..
I don't
On Fri, Sep 20, 2002 at 01:12:17PM -0400, Bruce Momjian wrote:
Tom has fixed it. Sorry I didn't test earlier.
Thanks.
Neil Conway wrote:
It seems the 'numeric' and 'int8' tests are failing in CVS HEAD. The
culprit seems to be the recent to_char() change made by Karel, but I
haven't
On Fri, Sep 20, 2002 at 09:24:00PM +0200, Peter Eisentraut wrote:
Karel Zak writes:
test=# select to_char(0,'FM9.9');
to_char
-
0.
(1 row)
test=# select to_char(1,'FM9.9');
to_char
-
1.
(1 row)
I find this highly bizzare. The FM modifier means to
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
Alvaro Herrera [EMAIL PROTECTED] writes:
Another interesting case is multiple inheritance.
create table p1 (f1 int);
create table p2 (f1 int);
create table c () inherits(p1, p2);
drop ONLY column p1.f1;
drop column p2.f1;
After
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
Alvaro Herrera [EMAIL PROTECTED] writes:
Another interesting case is multiple inheritance.
create table p1 (f1 int);
create table p2 (f1 int);
create table c () inherits(p1, p2);
drop ONLY column p1.f1;
drop column p2.f1;
After
Hannu Krosing dijo:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
Would it then not produce a situation, which can't be reproduced
En 23 Sep 2002 10:23:06 +0200
Hannu Krosing [EMAIL PROTECTED] escribió:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
This would not
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:06:
Hannu Krosing dijo:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
Would it
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:30:
En 23 Sep 2002 10:23:06 +0200
Hannu Krosing [EMAIL PROTECTED] escribió:
Tom Lane kirjutas P, 22.09.2002 kell 18:56:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count,
On Sun, 22 Sep 2002, Tom Lane wrote:
It was pretty clear that Thomas' original patch lost the vote, or
would have lost if we'd bothered to hold a formal vote.
Hasn't there just been a formal vote on this?
I don't
see anyone arguing against the notion of making XLOG location more
easily
Nigel J. Andrews wrote:
snip
And it's obvious it was centred on the use of an environment variable from the
subject line, it's still got PGXLOG in capitals in it.
Actually, to be really precise, my original email asked for an
environment variable. But only because I'd thought about it from
Hi All,
When I try 2 or 3 consecutive select count(*) on my database I've the
problem shown below.
Here is a psql session log:
[root@foradada root]# psql -d database
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL
On Sun, Sep 22, 2002 at 04:18:23PM -0400, Tom Lane wrote:
I had a thought about what to do with the ECPG grammar-too-big problem:
rather than depending on a beta release of bison, we could attack the
problem directly by omitting some of the backend grammar from what ECPG
supports. Surely
On Sun, 22 Sep 2002, Marc G. Fournier wrote:
Thomas implemented an option that he felt was useful, and that doesn't
break anything inside of the code ... he provided 2 methods of being able
to move the xlog's to another location (through command line and
environment variable, both of which
Hannu Krosing [EMAIL PROTECTED] writes:
Alvaro Herrera kirjutas E, 23.09.2002 kell 10:30:
The former drops f1 from c, while the latter does not. It's
inconsistent.
But this is what _should_ happen.
On what grounds do you claim that? I agree with Alvaro: it's
inconsistent to have ONLY
Hello All,
I have written a small daemon that can automatically vacuum PostgreSQL
database, depending upon activity per table.
It sits on top of postgres statistics collector. The postgres installation
should have per row statistics collection enabled.
Features are,
* Vacuuming based on
Hannu Krosing [EMAIL PROTECTED] writes:
I meant
create table p1 (f1 int, f2 int);
create table p2 (f1 int, f3 int);
create table c () inherits (p1, p2);
alter table only p1 drop column f1;
If you now set c.f1.attislocal = 1 as suggested by Tom , it seems like
you have a local p1.f1
On 23 Sep 2002 at 14:50, Lee Kindness wrote:
Shridhar,
Might be useful to add a .tag.gz to the downloads, so people do not
have to use CVS to take a look.
There is a development snapshot..
Bye
Shridhar
--
In most countries selling harmful things like drugs is punishable.Then howcome
Michael Meskes [EMAIL PROTECTED] writes:
On Sun, Sep 22, 2002 at 04:18:23PM -0400, Tom Lane wrote:
I had a thought about what to do with the ECPG grammar-too-big problem:
rather than depending on a beta release of bison, we could attack the
problem directly by omitting some of the backend
Hannu Krosing [EMAIL PROTECTED] writes:
It seems to me that DROP ONLY should set attislocal true on each child
for which it decrements the inherit count, whether the count reaches
zero or not.
Would it then not produce a situation, which can't be reproduced using
just CREATEs ? i.e. same
Roberto Fichera [EMAIL PROTECTED] writes:
database=# select count(*) from detail;
count
181661
(1 row)
database=# select count(*) from detail;
count
181660
(1 row)
database=# select count(*) from detail;
FATAL 2: open of /var/lib/pgsql/data/pg_clog/0303
At 10.40 23/09/02 -0400, Tom Lane wrote:
Roberto Fichera [EMAIL PROTECTED] writes:
database=# select count(*) from detail;
count
181661
(1 row)
database=# select count(*) from detail;
count
181660
(1 row)
database=# select count(*) from detail;
Bruce Momjian [EMAIL PROTECTED] writes:
7 . 3 O P E NI T E M S
Loading 7.2 pg_dumps
functions no longer public executable
languages no longer public usable
Although it's reasonably easy to fix no-privileges problems for
functions after you load a
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
7 . 3 O P E NI T E M S
Loading 7.2 pg_dumps
functions no longer public executable
languages no longer public usable
Although it's reasonably easy to fix no-privileges problems for
Hello.
I'm just curious as to the 7.3 status of a couple of things:
1. Back in Feb. I wrote (in regards to Oracle behavior):
Unlike normal queries where blocks are added to the MRU end of
an LRU list, full table scans add the blocks to the LRU end of
the LRU list. I was wondering, in the
Mike Mascari [EMAIL PROTECTED] writes:
Bruce wrote:
Yes, someone from India has a project to test LRU-K and MRU for
large table scans and report back the results. He will
implement whichever is best.
Did this make it into 7.3?
No, we never heard back from that guy. It is still a live
Mike Mascari wrote:
Hello.
I'm just curious as to the 7.3 status of a couple of things:
1. Back in Feb. I wrote (in regards to Oracle behavior):
Unlike normal queries where blocks are added to the MRU end of
an LRU list, full table scans add the blocks to the LRU end of
the LRU
Tom Lane wrote:
Another thing I'd like to see in the near future is a configurable
setting for the amount of memory space that can be used for temp-table
buffers. The current setting is ridiculously small (64*8K IIRC), but
there's not much point in increasing it until we also have a smarter
Tom Lane wrote:
Mike Mascari [EMAIL PROTECTED] writes:
Bruce wrote:
Yes, someone from India has a project to test LRU-K and MRU for
large table scans and report back the results. He will
implement whichever is best.
Did this make it into 7.3?
No, we never heard back from that
Tom Lane wrote:
Mike Mascari [EMAIL PROTECTED] writes:
Bruce wrote:
Yes, someone from India has a project to test LRU-K and MRU for
large table scans and report back the results. He will
implement whichever is best.
Did this make it into 7.3?
No, we never heard back from that guy. It is
Bruce Momjian [EMAIL PROTECTED] writes:
What do we do now? The author clearly got it in before beta, but we are
in beta now. I think we should apply it.
No. It's a feature addition and we are in feature freeze. Moreover,
it's an unreviewed feature addition (I certainly never had time to
Tom Lane [EMAIL PROTECTED] writes:
No, we never heard back from that guy. It is still a live topic though.
One of the Red Hat people was looking at it over the summer, and I think
Neil Conway is experimenting with LRU-2 code right now.
Just to confirm that, I'm working on this, and hope to
Well, it looks like it was already taken to the mat.
;)
Greg
On Thu, 2002-09-19 at 16:58, Joe Conway wrote:
Nigel J. Andrews wrote:
On Thu, 19 Sep 2002, Joe Conway wrote:
I can give it a shot, but probably not until the weekend.
I haven't really followed this thread closely, and don't
OK, I will save this for 7.4. Sorry, Gavin. I missed this one for 7.3.
---
pgman wrote:
Tom Lane wrote:
Mike Mascari [EMAIL PROTECTED] writes:
Bruce wrote:
Yes, someone from India has a project to test LRU-K and
Tom Lane wrote:
I have noticed a change in behavior following the recent changes for
casting of numeric constants. In prior releases, we got
regression=# select log(10.1);
log
--
1.00432137378264
(1 row)
CVS tip gives
regression=# select log(10.1);
Jan Wieck [EMAIL PROTECTED] writes:
One problem is, that division already has an inherently inexact
result. Do you intend to rip that out too while at it? (Just
kidding)
No, but that too is now delivering less precision than it used to:
regression=# select 10.1/7.0;
?column?
Tom Lane writes:
I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.
That seems reasonable. Since everyone is supposed to use createlang,
that's the effective default anyway.
--
Peter Eisentraut [EMAIL
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
I am thinking that the better course might be to have newly created
languages default to USAGE PUBLIC, at least for a release or two.
That seems reasonable. Since everyone is supposed to use createlang,
that's the effective
On Mon, 23 Sep 2002, Bruce Momjian wrote:
OK, I will save this for 7.4. Sorry, Gavin. I missed this one for 7.3.
Such is life.
Gavin
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Seems we need to resolve this before beta2.
---
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
One problem is, that division already has an inherently inexact
result. Do you intend to rip that out too while at
Bruce Momjian wrote:
Seems we need to resolve this before beta2.
I'd go with making the NUMERIC default precision 16 for v7.3, so
we are backwards compatible on this release (except that it is
now a predictable 16 digit precision instead of an hardware
implementation dependent one).
For v7.4
Bruce Momjian [EMAIL PROTECTED] writes:
Seems we need to resolve this before beta2.
Not really. It's just a bug; we have others.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Seems we need to resolve this before beta2.
Not really. It's just a bug; we have others.
Oh, it doesn't effect initdb?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
Illustra did a very nice job with composite types which
correspond to these record types. The composite types
were able to be used as a column type as jerome describes.
The subcolumns were accessed with dots. This gave us
schema.table.column.attribute
where of course attribute could
Hi all,
It occurs to me that opening web page on www.postgresql.org, asking the
user to select the mirror, is rather unprofessional. I am sure this has
been discussed before but I thought I would bring it up again anyway.
So, why not just redirect people to one of the mirrors listed? This could
Just following up on Tom Lane's email -
A couple of things that I hadn't mentioned: After bringing up the
machine, the first thing I did before mucking about with PostGreSQL was
to tarball $PGDATA so that I'd have a second chance if I messed up. I
then ran pg_resetlog -f the first time, as Tom
On Tue, 24 Sep 2002, Gavin Sherry wrote:
Hi all,
It occurs to me that opening web page on www.postgresql.org, asking the
user to select the mirror, is rather unprofessional. I am sure this has
been discussed before but I thought I would bring it up again anyway.
Already being worked on ...
could be done based on IP (yes it is inaccurate but it is close enough
and has the same net effect: pushing people off the main web server) or
it could be done by simply redirecting to a random mirror.
Have tried both in the past with disastrous results ...
What method will be employed
Just an FYI - this kind of thing would be a *great* feature addition to the generic
PostgresSQL release. We at Lyris often hear that postgressql is very slow, and the
files are getting larger and then wow! it's so much faster now that we're regularly
vacuuming! after we let them know about
Joe Conway wrote:
Oleg Lebedev wrote:
Ok, here are all the files.
This dblink thread on GENERAL led me to a bug in the planner subselect code.
Here is an example query that triggers it (independent of dblink and/or table
functions):
replica=# create table foo(f1 int);
CREATE TABLE
On 23 Sep 2002 at 13:28, Matthew T. O'Connor wrote:
On Monday 23 September 2002 09:43 am, Shridhar Daithankar wrote:
Hello All,
I have written a small daemon that can automatically vacuum PostgreSQL
database, depending upon activity per table.
Hello Shridhar, sorry I didn't respond
51 matches
Mail list logo
