Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Also, I thought Peter advocated adding -g a few releases back.
I don't recall any such vote.
The vote was whether -g should be used for a default compile.
Here is the thread discussing the -g
Dear friends,
I would like to port Compiere CRM from Oracle to PostgreSQL (and release it
for free).
At first I would like to convert the data schema. This is not difficult as
Compiere is written using portable types like NUMBER (i,d) which can be
replaced by NUMERIC (i,d), etc... A series of
Jean-Michel POURE writes:
Is there a way to map Oracle nvarchar2(lenght) to PostgreSQL varchar(lenght)
in PostgreSQL 7.3? Are there plans to allow such mapping in the future using
the CREATE DOMAIN syntax?
No to both. Doing this would most likely require making the affected type
names be
Tom Lane writes:
The CHECK_CONSTRAINTS view should use pg_get_constraintdef() function
rather than consrc, for the same reasons as psql should (I haven't fixed
the latter yet, but will soon).
True. Btw., is there a particular value in pg_get_constraintdef always
printing double pairs of
Is it possible to have an optional delay in plain VACUUM for each invocation
rather than database wide? Something along the line of an optional THROTTLE
or DELAY parameter for the VACUUM command. The THROTTLE is ignored when FULL
or FREEZE is selected.
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ]
Josh Berkus wrote:
Peter,
I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't
afford
to upgrade right now. Does such an animal exist? Help!
Install it from source if you cannot find a package.
Hmmm ... still getting the Bison Too Old warning
Tom Lane wrote:
I was just thinking of a GUC parameter: wait N milliseconds between
pages, where N defaults to zero probably. A user who wants to run his
vacuum as a background process could set N larger than zero. I don't
believe we are anywhere near being able to automatically adjust the
delay
Jean-Michel POURE wrote:
Dear friends,
I would like to port Compiere CRM from Oracle to PostgreSQL (and release it
for free).
At first I would like to convert the data schema. This is not difficult as
Compiere is written using portable types like NUMBER (i,d) which can be
replaced by NUMERIC
Shridhar Daithankar wrote:
Jean-Michel POURE wrote:
Dear friends,
I would like to port Compiere CRM from Oracle to PostgreSQL (and
release it for free).
At first I would like to convert the data schema. This is not
difficult as Compiere is written using portable types like NUMBER
(i,d)
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
I am slightly confused here. IIRC pg_autovacuum never did a vacuum full. At
the most it does vacuum /vacuum analyse, none of which chew disk bandwidth.
The latter is false. VACUUM FULL certainly uses _more_ disk
bandwidth
Peter Eisentraut [EMAIL PROTECTED] writes:
True. Btw., is there a particular value in pg_get_constraintdef always
printing double pairs of parentheses for CHECK constraints?
No, but it will require some restructuring of the code to get rid of it
safely (where safely is defined as never
Andrew Sullivan wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
I am slightly confused here. IIRC pg_autovacuum never did a vacuum full. At
the most it does vacuum /vacuum analyse, none of which chew disk bandwidth.
The latter is false. VACUUM FULL certainly uses
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
And if pg_autovacuum is running along with postmaster all the time, with
aggressive polling like 5 sec, the database should not accumulate any dead
tuples nor it would suffer xid wraparound as there are vacuum happening
Peter Eisentraut [EMAIL PROTECTED] writes:
Jean-Michel POURE writes:
Is there a way to map Oracle nvarchar2(lenght) to PostgreSQL varchar(lenght)
in PostgreSQL 7.3? Are there plans to allow such mapping in the future using
the CREATE DOMAIN syntax?
No to both. Doing this would most likely
Alvaro Herrera wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
And if pg_autovacuum is running along with postmaster all the time, with
aggressive polling like 5 sec, the database should not accumulate any dead
tuples nor it would suffer xid wraparound as there are
On Fri, Oct 17, 2003 at 07:41:38PM +0530, Shridhar Daithankar wrote:
Alvaro Herrera wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
The database can suffer XID wraparound anyway if there's at least one
table without updates, because the autovacuum daemon will
Shridhar Daithankar [EMAIL PROTECTED] writes:
What part of plain vacuum takes disk bandwidth?
Reading (and possibly rewriting) all the pages.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
Alvaro Herrera wrote:
On Fri, Oct 17, 2003 at 07:41:38PM +0530, Shridhar Daithankar wrote:
Alvaro Herrera wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
The database can suffer XID wraparound anyway if there's at least one
table without updates, because the
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
What part of plain vacuum takes disk bandwidth?
Reading (and possibly rewriting) all the pages.
I was under impression that was for shared memory pages only and not for disk pages.
OK. I can see difference of understanding here.
On Fri, 2003-10-17 at 04:10, Jean-Michel POURE wrote:
Dear friends,
I would like to port Compiere CRM from Oracle to PostgreSQL (and release it
for free).
This would be wonderful. However, I believe the guys at Compiere tried
to do this already and gave up on porting it to postgresql due
Shridhar Daithankar [EMAIL PROTECTED] writes:
Would it be possible to have a vacuum variant that would just shuffle thr.
shared buffers and not touch disk at all?
What would be the use of that? You couldn't predict *anything* about
the coverage. Maybe you find all the free space in a
On Fri, 2003-10-17 at 09:34, Shridhar Daithankar wrote:
I am slightly confused here. IIRC pg_autovacuum never did a vacuum full.
Correct.
At the
most it does vacuum /vacuum analyse,
Incorrect, it either does vacuum analyse, or just analyse
none of which chew disk bandwidth.
Incorrect,
On Fri, 17 Oct 2003, Tom Lane wrote:
Since varchar(n) is SQL-standard syntax, can't you simply adopt the more
standard name for both databases?
A long time ago Oracle made the varchar type equivalent to char and once
people complained about the excess space used by short entries they came
On Fri, Oct 17, 2003 at 07:55:44PM +0530, Shridhar Daithankar wrote:
OK. So here is what I understand. I have a table which contains 100 rows
which appeated there due to some insert operation. Then I vacuum it. And
sit there for internity for rest of the database to approach the
On Fri, 2003-10-17 at 10:25, Shridhar Daithankar wrote:
OK. So here is what I understand. I have a table which contains 100 rows which
appeated there due to some insert operation. Then I vacuum it. And sit there for
internity for rest of the database to approach the singularity(the xid
Le Vendredi 17 Octobre 2003 16:32, Matthew T. O'Connor a crit :
This would be wonderful. However, I believe the guys at Compiere tried
to do this already and gave up on porting it to postgresql due too a
couple of PostgreSQL limitations. I don't remember what they are
exactly, I think it had
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe in this case it's best to do a VACUUM FREEZE; that'd ensure that
the table would never ever need a vacuum again until it suffers
an insert, delete or update.
But how would you keep track of that? Certainly an external autovacuum
daemon couldn't
Matthew T. O'Connor wrote:
On Fri, 2003-10-17 at 10:25, Shridhar Daithankar wrote:
OK. So here is what I understand. I have a table which contains 100 rows which
appeated there due to some insert operation. Then I vacuum it. And sit there for
internity for rest of the database to approach the
Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
Would it be possible to have a vacuum variant that would just shuffle thr.
shared buffers and not touch disk at all?
What would be the use of that? You couldn't predict *anything* about
the coverage. Maybe you find all the free
On Fri, Oct 17, 2003 at 07:25:13PM +0530, Shridhar Daithankar wrote:
What part of plain vacuum takes disk bandwidth? WAL? Clog? Certainly not
data files themselves, right?
Sure, the data files. The data files still have to be completely
read from beginning to end by VACUUM.
A
--
On Fri, 2003-10-17 at 10:22, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
What part of plain vacuum takes disk bandwidth?
Reading (and possibly rewriting) all the pages.
Would it be possible for the backend to keep a list of the first N (N
being a large number but not
True. Btw., is there a particular value in pg_get_constraintdef always
printing double pairs of parentheses for CHECK constraints?
No, but it will require some restructuring of the code to get rid of it
safely (where safely is defined as never omitting any parentheses
that *are* necessary).
Rod Taylor wrote:
On Fri, 2003-10-17 at 10:22, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
What part of plain vacuum takes disk bandwidth?
Reading (and possibly rewriting) all the pages.
Would it be possible for the backend to keep a list of the first N (N
being a large
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
We could check the first character of the definition, and if it isn't a
left parenthesis, then we add parentheses.
And we would be wrong. Consider
(a 0) and (b 0)
regards, tom lane
Shridhar Daithankar [EMAIL PROTECTED] writes:
I agree. This seems to be the best way of dealing with things. Of course,
probably there are details we are missing here, but in general its good.
Actually, this is all pure handwaving, because you are ignoring the need
to remove index tuples. The
Alvaro Herrera [EMAIL PROTECTED] writes:
The trick to keep in mind is that the XID comparison functions use
modulo operations, _but_ there are special frozen XIDs that are
always committed -- that's why a VACUUM FREEZE would relieve the table
forever from this problem.
(At least this is how
On Fri, 2003-10-17 at 10:53, Shridhar Daithankar wrote:
Matthew T. O'Connor wrote:
One additional thing, some of this might be possible if pg_autovacuum
saved its data between restarts. Right now it restarts with no memory
of what happened before.
Well, the unmaintened gborg version
[EMAIL PROTECTED] (Shridhar Daithankar) writes:
Andrew Sullivan wrote:
On Fri, Oct 17, 2003 at 07:04:45PM +0530, Shridhar Daithankar wrote:
I am slightly confused here. IIRC pg_autovacuum never did a vacuum
full. At the most it does vacuum /vacuum analyse, none of which
chew disk
[EMAIL PROTECTED] (Shridhar Daithankar) writes:
Tom Lane wrote:
I was just thinking of a GUC parameter: wait N milliseconds between
pages, where N defaults to zero probably. A user who wants to run his
vacuum as a background process could set N larger than zero. I don't
believe we are
Tom,
Really? 'cause I got the warning from the Beta4 tarball.
If you mean the configure warning, sure, but the build won't fail.
Might I suggest changing the wording in the final release, then? The warning
sure looked dangerous; I aborted the build and went looking for bison 1.875
Josh Berkus writes:
Might I suggest changing the wording in the final release, then? The warning
sure looked dangerous;
It only looks dangerous to those who don't actually read the full text of
the message.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
Christopher Browne [EMAIL PROTECTED] writes:
VACUUM is like putting an extra few transport trucks onto the highway.
It may only go from one highway junction to the next, and be fairly
brief, if traffic is moving well. But if traffic is heavy, it adds to
the congestion. (And that's as far as
Greg Stark wrote:
Christopher Browne [EMAIL PROTECTED] writes:
VACUUM is like putting an extra few transport trucks onto the highway.
It may only go from one highway junction to the next, and be fairly
brief, if traffic is moving well. But if traffic is heavy, it adds to
the congestion. (And
Last night I just upgraded to a nightly snapshot of 7.4 and noticed an
error on queries that had previously worked (in version 7.3.x and
previous 7.4's snapshots up to about a month old).
I have a view that I can distill into a base case of:
CREATE VIEW testing_v AS
SELECT table_a.*
Hi,
It's been quite a while ago that I did NetWare programming (3.11 NLM,
communication protocol for a dbms), and that I had some contact with
Netware (4.1), but if Novell didn't change the architecture completely
(I doubt that) the native win32 port won't be of any help for
They've done the
[EMAIL PROTECTED] (Seun Osewa) wrote in message news:[EMAIL PROTECTED]...
Hi,
This is for relational database theory experts on one hand and
imlementers of real-world alications on the other hand. If there was
a chance to start again and design SQL afresh, for best
In article [EMAIL PROTECTED], Gene Wirchenko
[EMAIL PROTECTED] writes
[EMAIL PROTECTED] (Seun Osewa) wrote:
[snip]
Sometimes I wonder why its so important to model data in the rela-
tional way, to think of data in form of sets of tuples rather than
tables or lists or whatever. I mean, though
The more I think about this vacuum i/o problem, the more I think we have it
wrong. The added i/o from vacuum really ought not be any worse than a single
full table scan. And there are probably the occasional query doing full table
scans already in those systems.
For the folks having this issue,
On Fri, 2003-10-17 at 16:22, Greg Stark wrote:
If it's just a matter of all the read i/o from vacuum then we're best off
sleeping for a few milliseconds every few kilobytes. If it's the cache then
we're probably better off reading a few megabytes and then sleeping for
several seconds to allow
On Fri, 2003-10-17 at 14:56, Mike Mascari wrote:
Greg Stark wrote:
Ooh strained metaphors. This game is always fun.
So I think of it the other way around. A busy database is like downtown
traffic with everyone going every which way for short trips. Running vacuum is
like having a few
[EMAIL PROTECTED] (Mike Mascari) writes:
Greg Stark wrote:
Christopher Browne [EMAIL PROTECTED] writes:
VACUUM is like putting an extra few transport trucks onto the
highway. It may only go from one highway junction to the next, and
be fairly brief, if traffic is moving well. But if traffic is
Quoth Anthony W. Youngman [EMAIL PROTECTED]:
In article [EMAIL PROTECTED], Gene Wirchenko
[EMAIL PROTECTED] writes
[EMAIL PROTECTED] (Seun Osewa) wrote:
[snip]
Sometimes I wonder why its so important to model data in the rela-
tional way, to think of data in form of sets of tuples rather than
Neil Conway [EMAIL PROTECTED] writes:
Uh, no -- if it is the cache, we're better off fixing the buffer
replacement policy, not trying to hack around it.
If we can. As long as we are largely depending on the kernel's buffer
cache, we may not be able to just fix it ...
Sean P. Thomas [EMAIL PROTECTED] writes:
I get:
JOIN qualification may not refer to other relations
Problem confirmed here, will look into it. I have a feeling this is a
bad side-effect of this patch:
2003-10-13 19:48 tgl
* src/backend/optimizer/prep/prepjointree.c:
Hello All:
As the new Editor-N-Cheif of PostgreSQL.Org it is my job to make
sure that people who want to write about
PostgreSQL, can. I will be in constant communication with various
publications and will be helping in the
advocacy of PostgreSQL through wide spread dissemination
55 matches
Mail list logo
