On Mar 9, 2007, at 6:42 AM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Now regarding your restartable vacuum work. I think that stopping a
vacuum at some point and being able to restart it later is very
cool and
may get you some hot chicks, but I'm not sure it's really
Since partition is inheritance-based, a simple DROP or NO
INHERIT
will do the job to deal with the partition. Do we want to reinvent
additional syntax when these are around and are documented?
Well, if the syntax for adding a new partition eventually
ends up as ALTER TABLE ADD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gaetano Mendola wrote:
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
[ 8.2 evaluates volatile functions in the targetlist of a view ]
If I mark the function as STABLE or IMMUTABLE then even with version
8.2 the function is not
Hi all,
I am adding some new files into the system, so I wonder what I need
to do to
update the Makefiles?
Is the system smart enough to recognize my new files and add
corresponding entries into the Makefiles?
Thanks.
Regards
Yu
---(end of
Am Freitag, 9. März 2007 10:38 schrieb Cao Yu:
Is the system smart enough to recognize my new files and add
corresponding entries into the Makefiles?
No, you need to add it yourself. Look for where the other files are listed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Fri, 2007-03-09 at 11:48 +0530, NikhilS wrote:
Hi,
On 3/9/07, Shane Ambler [EMAIL PROTECTED] wrote:
Note to Nikhil: Make sure the new syntax doesn't prevent
partitions from
being placed upon multiple tablespaces in some manner, at
CREATE
Is there a particular reason why CLUSTER isn't MVCC-safe? It seems to me
that it would be trivial to fix, by using SnapshotAny instead of
SnapshotNow, and not overwriting the xmin/xmax with the xid of the
cluster command.
I feel that I must missing something, or someone would've already fixed
On Fri, Mar 09, 2007 at 08:16:12AM +, Dave Page wrote:
Magnus Hagander wrote:
For example, do you recall us being confused
when we found we needed to call it in slon.exe?
Eh, no, actually not. Sorry.
Well, it was only a couple of years ago!! Seriously though, from what I
recall that
Hi,
Why would we support HASH partitions?
If you did, the full syntax for hash clusters should be supported.
In MySQL, Oracle, the syntax for HASH partitions seems to be similar to the
one mentioned. I do not know much about hash clusters though.
If we do the CHECK clauses like that then
Tom Lane wrote:
Even more to the point, getting paid for has almost nothing to do
with has commit privileges. At least on this project.
Darn. So the cheque isn't really in the mail?
cheers
andrew
---(end of broadcast)---
TIP 2: Don't
On Fri, 2007-03-09 at 12:29, Heikki Linnakangas wrote:
Csaba, you mentioned recently
(http://archives.postgresql.org/pgsql-hackers/2007-03/msg00027.php) that
you're actually using the MVCC-violation to clean up tables during a
backup. Can you tell us a bit more about that? Would you be
Ühel kenal päeval, R, 2007-03-09 kell 11:29, kirjutas Heikki
Linnakangas:
Is there a particular reason why CLUSTER isn't MVCC-safe? It seems to me
that it would be trivial to fix, by using SnapshotAny instead of
SnapshotNow, and not overwriting the xmin/xmax with the xid of the
cluster
Tom Lane [EMAIL PROTECTED] writes:
Er, why not just finish out the scan at the reduced I/O rate? Any sort
of abort behavior is going to create net inefficiency, eg doing an
index scan to remove only a few tuples. ISTM that the vacuum ought to
just continue along its existing path at a
Simon,
What happens to the data when the function is dropped or replaced?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: Friday, March 09, 2007 06:20 AM Eastern Standard Time
To: NikhilS
Cc: Shane Ambler; Luke
Csaba Nagy [EMAIL PROTECTED] writes:
Wouldn't be possible to do it like Simon (IIRC) suggested, and add a
parameter to enable/disable the current behavior, and use the MVCC
behavior as default ?
Doing it in CLUSTER would be weird. However perhaps it would be useful to have
some sort of
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Er, why not just finish out the scan at the reduced I/O rate? Any sort
of abort behavior is going to create net inefficiency, eg doing an
index scan to remove only a few tuples. ISTM that the vacuum ought to
just continue along
On Fri, 2007-03-09 at 13:42, Gregory Stark wrote:
Csaba Nagy [EMAIL PROTECTED] writes:
Wouldn't be possible to do it like Simon (IIRC) suggested, and add a
parameter to enable/disable the current behavior, and use the MVCC
behavior as default ?
Doing it in CLUSTER would be weird.
Csaba Nagy wrote:
On Fri, 2007-03-09 at 12:29, Heikki Linnakangas wrote:
Csaba, you mentioned recently
(http://archives.postgresql.org/pgsql-hackers/2007-03/msg00027.php) that
you're actually using the MVCC-violation to clean up tables during a
backup. Can you tell us a bit more about that?
Gregory Stark wrote:
Csaba Nagy [EMAIL PROTECTED] writes:
Wouldn't be possible to do it like Simon (IIRC) suggested, and add a
parameter to enable/disable the current behavior, and use the MVCC
behavior as default ?
Doing it in CLUSTER would be weird. However perhaps it would be useful
Is there a particular reason why CLUSTER isn't MVCC-safe? It seems
to
me that it would be trivial to fix, by using SnapshotAny instead of
SnapshotNow, and not overwriting the xmin/xmax with the xid of the
cluster command.
It's trivial to fix now in this way, but it would break HOT,
On Fri, 2007-03-09 at 14:00, Alvaro Herrera wrote:
But I'm not really seeing the problem here. Why isn't Csaba's problem
fixed by the fact that HOT reduces the number of dead tuples in the
first place? If it does, then he no longer needs the CLUSTER
workaround, or at least, he needs it to a
Hmm. You could use something along these lines instead:
0. LOCK TABLE queue_table
1. SELECT * INTO queue_table_new FROM queue_table
2. DROP TABLE queue_table
3. ALTER TABLE queue_table_new RENAME queue_table
After all, it's not that you care about the clustering of the table, you
just
On Fri, 9 Mar 2007, ITAGAKI Takahiro wrote:
Pinned means bufHdr-refcount 0 and you don't distinguish pinned or
recently-used (bufHdr-usage_count 0) buffers in your patch.
Thank you, I will revise the terminology used accordingly. I was using
pinned as a shortcut for will be ignored by
On Fri, 2007-03-09 at 07:40 -0500, Luke Lonergan wrote:
What happens to the data when the function is dropped or replaced?
Well, that wouldn't happen because you build in a dependency.
I'm not working on this, so don't expect lots of detail. The idea is
essentially to implement things the way
Reviewing earlier threads, I realised that there was a potential
bug/loophole in PITR backups in conjunction with avoiding WAL for bulk
operations. This would be rare, but should be fixed.
http://archives.postgresql.org/pgsql-hackers/2006-05/msg01113.php
Say you issue COPY, CREATE INDEX etc..
Magnus Hagander wrote:
In which case it can simply be because I was building against a libpq
built with MSVC = it had the broken startup code, and you used a mingw
one, which didn't have it.
Maybe - but it does imply it's potentially easy to break code with this
change.
Per the docs, an
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x = 8.2.3 and I had on
first hour of service up
lot of queries blocked due to this, consider in my case I have on v_ta
milions of records and usually
that join extracts 1 row.
On Thu, Mar 08, 2007 at 07:01:17PM -0500, Umar Farooq Minhas wrote:
displayed, I want cpu cost and io cost displayed separated when i run
EXPLAIN on a particular query. Till now I haven't been able to figure
out a 'clean' way of doing this. Can anyone tell me how much time
should I expect to
Csaba Nagy wrote:
On Fri, 2007-03-09 at 14:00, Alvaro Herrera wrote:
But I'm not really seeing the problem here. Why isn't Csaba's problem
fixed by the fact that HOT reduces the number of dead tuples in the
first place? If it does, then he no longer needs the CLUSTER
workaround, or at least,
Martijn van Oosterhout kleptog@svana.org writes:
Most people figured it was a improvment. It's configured per function
now, which wasn't the case before. I dont't think there was ever any
discussion about having a global switch.
Volatile functions that are not at the top level of a query are
Martijn van Oosterhout wrote:
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x = 8.2.3 and I had on
first hour of service up
lot of queries blocked due to this, consider in my case I have on v_ta
milions of records and
Heikki Linnakangas wrote:
Csaba Nagy wrote:
On Fri, 2007-03-09 at 14:00, Alvaro Herrera wrote:
But I'm not really seeing the problem here. Why isn't Csaba's problem
fixed by the fact that HOT reduces the number of dead tuples in the
first place? If it does, then he no longer needs the
Martijn van Oosterhout wrote:
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x = 8.2.3 and I had on
first hour of service up
lot of queries blocked due to this, consider in my case I have on v_ta
milions of records and
Csaba Nagy wrote:
Hmm. You could use something along these lines instead:
0. LOCK TABLE queue_table
1. SELECT * INTO queue_table_new FROM queue_table
2. DROP TABLE queue_table
3. ALTER TABLE queue_table_new RENAME queue_table
After all, it's not that you care about the clustering of the table,
Zeugswetter Andreas ADI SD wrote:
Is there a particular reason why CLUSTER isn't MVCC-safe? It seems
to
me that it would be trivial to fix, by using SnapshotAny instead of
SnapshotNow, and not overwriting the xmin/xmax with the xid of the
cluster command.
It's trivial to fix
Florian G. Pflug wrote:
Couldn't HOT in principle deal with this? Let's say you have two
long-running
transactions, which see row versions A and D. While those transactions
are running, the row is constantly updated, leading to row versions B, C
(before
the second long-running transaction
On 3/9/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Heikki Linnakangas wrote:
Csaba Nagy wrote:
On Fri, 2007-03-09 at 14:00, Alvaro Herrera wrote:
But I'm not really seeing the problem here. Why isn't Csaba's problem
fixed by the fact that HOT reduces the number of dead tuples in the
Mike Rylander wrote:
On 3/9/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Couldn't HOT in principle deal with this? Let's say you have two
long-running
transactions, which see row versions A and D. While those transactions
are running, the row is constantly updated, leading to row versions B,
Gaetano Mendola wrote:
Martijn van Oosterhout wrote:
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x = 8.2.3 and I had on
first hour of service up
lot of queries blocked due to this, consider in my case I have on v_ta
Heikki Linnakangas [EMAIL PROTECTED] writes:
Is there a particular reason why CLUSTER isn't MVCC-safe? It seems to me
that it would be trivial to fix, by using SnapshotAny instead of
SnapshotNow, and not overwriting the xmin/xmax with the xid of the
cluster command.
The reason it's not
Dave Page [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Another question related to backpatching - should I backpatch this to
8.1 and 8.0 as well?
I'm far from convinced it should be backpatched at all.
I tend to agree with Dave --- I think this change needs to go through a
beta-testing
On Thu, Mar 08, 2007 at 12:10:22 -0800,
Christian Bird [EMAIL PROTECTED] wrote:
I'm a grad student at UC Davis studying the postgres community and I
wanted to know if some on this list could help me out. I'm studying
the factors that affect people graduating from being mailing list
On Fri, 2007-03-09 at 12:48 -0300, Alvaro Herrera wrote:
Zeugswetter Andreas ADI SD wrote:
Is there a particular reason why CLUSTER isn't MVCC-safe? It seems
to
me that it would be trivial to fix, by using SnapshotAny instead of
SnapshotNow, and not overwriting the xmin/xmax
Simon Riggs [EMAIL PROTECTED] writes:
Say you issue COPY, CREATE INDEX etc..
pg_start_backup()
pg_stop_backup()
...then bulk operation ends.
This will result in a base backup that does not contain the data written
during the bulk operation and the changes aren't in WAL either.
Uh, no. The
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Is there a particular reason why CLUSTER isn't MVCC-safe? It seems to me
that it would be trivial to fix, by using SnapshotAny instead of
SnapshotNow, and not overwriting the xmin/xmax with the xid of the
cluster command.
The
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Say you issue COPY, CREATE INDEX etc..
pg_start_backup()
pg_stop_backup()
...then bulk operation ends.
This will result in a base backup that does not contain the data written
during the bulk
Heikki Linnakangas [EMAIL PROTECTED] writes:
We wouldn't clean up tuples that are visible to a transaction, but if
you have one long-running transaction like pg_dump in a database with
otherwise short transaction, you'll have a lot of tuples that are not
vacuumable because of the
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
We wouldn't clean up tuples that are visible to a transaction, but if
you have one long-running transaction like pg_dump in a database with
otherwise short transaction, you'll have a lot of tuples that are not
vacuumable because of
Heikki Linnakangas wrote:
The implementation problem is that we don't have a global view of all
snapshots in the system. If we solve that, we can be more aggressive
with vacuuming in presence of long-running transactions. It's not an
easy problem, we don't want to add a lot of accounting
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
It strikes me that allowing archive_command to be changed on the fly
might not be such a good idea though, or at least it shouldn't be
possible to flip it from empty to nonempty during live operation.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
We wouldn't clean up tuples that are visible to a transaction, but if
you have one long-running transaction like pg_dump in a database with
otherwise short transaction, you'll have a lot of tuples that are not
vacuumable because of
On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
It strikes me that allowing archive_command to be changed on the fly
might not be such a good idea though, or at least it shouldn't be
possible to
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
It strikes me that allowing archive_command to be changed on the fly
might not be such a good idea though, or at least it shouldn't be
possible to flip it from empty to nonempty
On Fri, 2007-03-09 at 17:47, Tom Lane wrote:
I don't think that people are very likely to need to turn archiving on
and off on-the-fly.
We did need occasionally to turn archiving on on-the-fly. It did happen
that I started up a new DB machine and I did not have yet the log
archive available, so
It would be interested to see some code here.
Maybe this would be a great oportunity to start - some sort of 'auto-
tune' (as an option), in the area.
--
GJ
C/C++/SQL freelance to hire.
---(end of broadcast)---
TIP 4: Have you searched our
Cool!
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: Friday, March 09, 2007 02:32 PM Eastern Standard Time
To: Luke Lonergan; ITAGAKI Takahiro
Cc: Sherry Moore; Tom Lane; Mark Kirkwood; Pavan Deolasee; Gavin Sherry;
Andrew Dunstan wrote:
Tom Lane wrote:
Even more to the point, getting paid for has almost nothing to do
with has commit privileges. At least on this project.
Darn. So the cheque isn't really in the mail?
I think his question was just which ratio of developers works on
PostgreSQL on
On Mar 8, 2007, at 11:51 PM, Greg Smith wrote:
almost everything that's dirty is also pinned during pgbench, and
the LRU is lucky to find anything it can write as a result
I'm wondering if pg_bench is a good test of this stuff. ISTM it's
unrealistically write-heavy, which is going to tend
On Mar 8, 2007, at 11:51 PM, Greg Smith wrote:
almost everything that's dirty is also pinned during pgbench, and
the LRU is lucky to find anything it can write as a result
I'm wondering if pg_bench is a good test of this stuff. ISTM it's
unrealistically write-heavy, which is going to tend
On Mar 9, 2007, at 7:57 AM, Greg Smith wrote:
On Fri, 9 Mar 2007, ITAGAKI Takahiro wrote:
Pinned means bufHdr-refcount 0 and you don't distinguish
pinned or recently-used (bufHdr-usage_count 0) buffers in your
patch.
Thank you, I will revise the terminology used accordingly. I was
Pavan Deolasee [EMAIL PROTECTED] writes:
The problem mentioned before is hard to reproduce with the
suggested change, but its not completely gone away. I have
seen that again on CVS HEAD with the patch applied.
I am facing another issue with VACUUM FULL. This
problem gets reproduced with HOT
On Mar 9, 2007, at 3:31 AM, Zeugswetter Andreas ADI SD wrote:
Since partition is inheritance-based, a simple DROP or NO
INHERIT
will do the job to deal with the partition. Do we want to reinvent
additional syntax when these are around and are documented?
Well, if the syntax for adding a new
Ühel kenal päeval, R, 2007-03-09 kell 15:41, kirjutas Jim Nasby:
On Mar 9, 2007, at 3:31 AM, Zeugswetter Andreas ADI SD wrote:
Since partition is inheritance-based, a simple DROP or NO
INHERIT
will do the job to deal with the partition. Do we want to reinvent
additional syntax when these
Christian Bird wrote:
Hi all,
I'm a grad student at UC Davis studying the postgres community and I
wanted to know if some on this list could help me out. I'm studying
the factors that affect people graduating from being mailing list
participant to developers with write access to the
On Fri, 2007-03-09 at 16:40 -0500, Tom Lane wrote:
I wonder whether this has any implications for HOT ...
My general feeling, expressed in a number of recent posts was that the
VACUUM FULL code really isn't worth the trouble it causes. Especially
when CLUSTER does a better job anyway?
I've
Here is a low-level, very detailed description of the implementation of
the autovacuum ideas we have so far.
launcher's dealing with databases
-
We'll add a new member nexttime to the autovac_dbase struct, which
will be the time_t of the next time a worker needs
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 16:40 -0500, Tom Lane wrote:
I wonder whether this has any implications for HOT ...
My general feeling, expressed in a number of recent posts was that the
VACUUM FULL code really isn't worth the trouble it causes. Especially
when
Put it another way: if anybody submitted a patch that does what VACUUM
FULL does, coded in the way it is, it would never be applied, now.
Have an opinion do we? How about we just alias VACUUM FULL to cluster
and add the reporting stuff from VERBOSE?
Joshua D. Drake
--
=== The
Jim Nasby [EMAIL PROTECTED] writes:
On Mar 8, 2007, at 11:51 PM, Greg Smith wrote:
almost everything that's dirty is also pinned during pgbench, and
the LRU is lucky to find anything it can write as a result
I'm wondering if pg_bench is a good test of this stuff.
On reflection I think that
My initial reaction is that this looks good to me, but still a few
comments below.
Alvaro Herrera wrote:
Here is a low-level, very detailed description of the implementation of
the autovacuum ideas we have so far.
launcher's dealing with databases
-
[ Snip ]
Joshua D. Drake wrote:
Christian Bird wrote:
Hi all,
I'm a grad student at UC Davis studying the postgres community and I
wanted to know if some on this list could help me out. I'm studying
the factors that affect people graduating from being mailing list
participant to developers with write
Matthew T. O'Connor matthew@zeut.net writes:
Does a new worker really care about the PID of other workers or what
table they are currently working on?
As written, it needs the PIDs so it can read in the other workers' todo
lists (which are in files named by PID).
It's not clear to me why a
On Fri, 9 Mar 2007, Jim Nasby wrote:
I'm wondering if pg_bench is a good test of this stuff. ISTM it's
unrealistically write-heavy, which is going to tend to not only put a
lot of dirty buffers into the pool, but also keep them pinned enough
that you can't write them.
Whether it's
Tom Lane [EMAIL PROTECTED] writes:
It's not surprising that tuples could have xmax less than xmin, since
transactions can commit in orders different than they start; when using
READ COMMITTED updates it's not at all surprising that a transaction
might update rows after a later-numbered
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
It's not clear to me why a worker cares that there is a new worker,
since the new worker is going to ignore all the tables that are already
claimed by all worker todo lists.
That seems wrong to me, since it means that new workers
Gregory Stark [EMAIL PROTECTED] writes:
So txn 4's xmin is txn 3, leaving the global OldestXmin = txn 3 which lies
between txn 1 and txn 2.
And the tuple chain consists of two tuples. The original which has xmax
younger than OldestXmin and so is RECENTLY_DEAD. And the updated tuple which
has
On Fri, 9 Mar 2007, Tom Lane wrote:
I'd be interested to know what scale factor and shared_buffers setting
led to the above measurement.
That was just a trivial example with 1 client, scale=10 (~160MB database),
and shared_buffers=24MB. Where things really get interesting with pgbench
is
Tom Lane [EMAIL PROTECTED] writes:
Hm, I wonder if you could just notice that xmin is younger than OldestXmin.
You can see that at the newer tuple, but the problem is to propagate the
knowledge back to the older tuple(s). Or were you suggesting that we
treat the newer tuple as
Gregory Stark [EMAIL PROTECTED] writes:
Breaking the chain up into pieces seems weird. It seems like it's obviously
bogus and only works because we're sure the tuples are dead anyways so it
doesn't really matter what we do with them.
Yup, exactly. If we wanted to be tense about this we'd try
Hi,
Was wondering if people would mind having a read over what I plan to do for my
undergraduate honours project - you can get the proposal here:
http://www.mcs.vuw.ac.nz/~eddie/489_Proposal.pdf
What I'd basically like to know is
a) Is this problem worth solving?
b) Is there already a good
Florian G. Pflug wrote:
Gaetano Mendola wrote:
Martijn van Oosterhout wrote:
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x = 8.2.3 and I
had on first hour of service up
lot of queries blocked due to this, consider in my
I didn't mean to imply that getting paid is correlated with getting
commit privileges. However, there is literature that supports the
idea that those who are under employ to help in OSS projects may
behave differently than those who are contributing in their free time
(check out
Florian G. Pflug wrote:
Martijn van Oosterhout wrote:
On Fri, Mar 09, 2007 at 10:59:56AM +0100, Gaetano Mendola wrote:
Is really this what we want? I did a migration 8.0.x = 8.2.3 and I
had on first hour of service up
lot of queries blocked due to this, consider in my case I have on
v_ta
Magnus Hagander wrote:
On Tue, Jan 23, 2007 at 11:39:23AM -0800, Jeremy Drake wrote:
On Tue, 23 Jan 2007, Magnus Hagander wrote:
On Tue, Jan 23, 2007 at 09:31:40AM -0500, Andrew Dunstan wrote:
Magnus Hagander wrote:
Hi!
I get failures for the largeobject regression
On Friday 09 March 2007 01:23, NikhilS wrote:
Hi,
This follows on from the suggestion I made - taken along the lines of
the subject auto creation of partitions where I suggested the syntax
of partition check(month of mydatecol) and have a new partition created
as data was entered. With
Hi,
On 3/10/07, Hannu Krosing [EMAIL PROTECTED] wrote:
Ühel kenal päeval, R, 2007-03-09 kell 15:41, kirjutas Jim Nasby:
On Mar 9, 2007, at 3:31 AM, Zeugswetter Andreas ADI SD wrote:
Since partition is inheritance-based, a simple DROP or NO
INHERIT
will do the job to deal with the
Hi,
Given that Simon wants to do away with having the master table APPENDed
in
the planning phase, this would be better.
ISTM you're trading appending the master table for appending the DUMP
partition, which afaict would give you no gain.
If there are entries in the master table, I
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
I wonder if this is a line-end issue? Assuming you are working from CVS,
does your client turn \n into \r\n ?
I have just run into this today while trying to get buildfarm working
for MSVC. After some consideration I think an
Gaetano Mendola [EMAIL PROTECTED] writes:
I can immagine a case when a lower module exports a view to upper layer
stating
the interface as list of fields:
first_name, last_name,
with an *hidden* field that is a function call that updates the statistics on
how many time a given record
89 matches
Mail list logo
