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
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 thin
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 th
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
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 ente
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 t
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 hav
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
http://gsyc.info
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 t
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 s
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
"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 REC
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 on
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
Tom Lane wrote:
"Matthew T. O'Connor" 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 will ignore
tabl
"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
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 "unrealist
"Matthew T. O'Connor" 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 worker cares
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
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 ]
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 thi
> 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 Pos
"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
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
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 prop
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
Ü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
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 ne
"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 w
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
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 to
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 to
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 o
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;
On Tue, 2007-03-06 at 22:32 -0500, Luke Lonergan wrote:
> Incidentally, we tried triggering NTA (L2 cache bypass)
> unconditionally and in various patterns and did not see the
> substantial gain as with reducing the working set size.
>
> My conclusion: Fixing the OS is not sufficient to alleviate
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 list
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, s
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
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
> >>
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
"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 opera
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 overhe
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 <[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 long-
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
> > duri
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 rea
"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,
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
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
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-te
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 no
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
mi
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,
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
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 star
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
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,
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 reco
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 CLUSTER
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 usu
Martijn van Oosterhout 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 *always*
going t
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, h
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 t
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
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 ap
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..
pg_s
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 wa
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 ignore
> 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
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
> > 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 br
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 wo
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? Wo
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
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 c
"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
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 Lonerg
"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 a
On Fri, 2007-03-09 at 11:29 +, Heikki Linnakangas 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
Ü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 c
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 u
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
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 we
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
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, 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
>
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/
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 broadcast)--
-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 i
> > 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 TA
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 usef
91 matches
Mail list logo
