On 24 Sep 2002 at 8:42, Mario Weilguni wrote:
> Am Dienstag, 24. September 2002 08:16 schrieb Shridhar Daithankar:
> IMO there are still several problems with that approach, namely:
> * every database will get "polluted" with the autovacuum table, which is undesired
I agree. But that was the be
Am Dienstag, 24. September 2002 08:16 schrieb Shridhar Daithankar:
>
> > I will play with it more and give you some more feedback.
>
> Awaiting that.
>
IMO there are still several problems with that approach, namely:
* every database will get "polluted" with the autovacuum table, which is undesir
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
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
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
> > 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 em
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
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 s
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
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 i
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] |
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?
h
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.
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
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
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 effectiv
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 PRO
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(1
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 tes
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
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
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 t
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
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 ba
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 smart
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
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
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 lig
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 prob
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 l
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=# sele
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
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
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 bac
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
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
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 acti
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 ON
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 whic
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
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 comm
"Nigel J. Andrews" wrote:
>
> 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
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
> ea
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 inher
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.
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
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 repro
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
49 matches
Mail list logo
