On Thu, 2011-01-20 at 21:36 +, Simon Riggs wrote:
I'll review your patch and commit it, problems or objections excepted.
Tom's comments elsewhere prevent me from committing.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
First, I'd like to note that the thread for this patch had *four* me-too
responses to the use case. That's extremely unusual; the subject is
definitely
compelling to people. It addresses the bad behavior of natural attempts to
On Wed, 2011-01-19 at 22:16 -0500, Robert Haas wrote:
That's another way of saying the patch is not anywhere close to being done.
My patch is materially incomplete. Certainly we may see that as grounds
for rejection, which I would not and could not argue with. It is a
popular feature, so I
On Thu, Jan 20, 2011 at 10:07:23AM +, Simon Riggs wrote:
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
First, I'd like to note that the thread for this patch had *four* me-too
responses to the use case. That's extremely unusual; the subject is
definitely
compelling to
Noah Misch n...@leadboat.com writes:
Heikki's suggestion seemed straightforward, so much so that I couldn't figure
why nobody had done it. That would usually mean I'm missing something.
If you're willing to substitute an incompatible table, it's not clear
why you don't just do
On Thu, 2011-01-20 at 13:14 -0500, Noah Misch wrote:
When DDL has taken AccessExclusiveLock and a query waits for it, it's the
Right
Thing for that query to wake up and proceed based on the complete, final state
of that committed DDL. Aside from the waiting itself, the query should behave
On Thu, Jan 20, 2011 at 4:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Noah Misch n...@leadboat.com writes:
Heikki's suggestion seemed straightforward, so much so that I couldn't figure
why nobody had done it. That would usually mean I'm missing something.
If you're willing to substitute an
On Thu, Jan 20, 2011 at 09:36:11PM +, Simon Riggs wrote:
I agree that the DDL behaviour is wrong and should be fixed. Thank you
for championing that alternative view.
Swapping based upon names only works and is very flexible, much more so
than EXCHANGE could be.
A separate utility
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 20, 2011 at 4:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If you're willing to substitute an incompatible table, it's not clear
why you don't just do
begin;
drop table t;
alter table t_new
On Thu, Jan 20, 2011 at 11:17 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2011-01-19 at 22:16 -0500, Robert Haas wrote:
That's another way of saying the patch is not anywhere close to being done.
My patch is materially incomplete. Certainly we may see that as grounds
for rejection,
On Thu, Jan 20, 2011 at 6:19 PM, Noah Misch n...@leadboat.com wrote:
On Thu, Jan 20, 2011 at 09:36:11PM +, Simon Riggs wrote:
I agree that the DDL behaviour is wrong and should be fixed. Thank you
for championing that alternative view.
Swapping based upon names only works and is very
Hi Simon,
I'm reviewing this patch for CommitFest 2011-01.
On Sat, Jan 15, 2011 at 10:02:03PM +, Simon Riggs wrote:
On Tue, 2010-12-14 at 19:48 +, Simon Riggs wrote:
REPLACE TABLE ying WITH yang
Patch. Needs work.
First, I'd like to note that the thread for this patch had *four*
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
I'll go ahead and mark the patch Returned with Feedback.
My understanding of the meaning of that is polite rejection. If you do
that there is no further author comment and we move to July 2011. That
then also rejects your own patch with what
On Thu, Jan 20, 2011 at 12:57:23AM +, Simon Riggs wrote:
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
I'll go ahead and mark the patch Returned with Feedback.
My understanding of the meaning of that is polite rejection. If you do
that there is no further author comment and we
On Wed, Jan 19, 2011 at 7:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
I'll go ahead and mark the patch Returned with Feedback.
My understanding of the meaning of that is polite rejection. If you do
that there is no further author
On Wed, Jan 19, 2011 at 08:55:22PM -0500, Robert Haas wrote:
On Wed, Jan 19, 2011 at 7:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
I'll go ahead and mark the patch Returned with Feedback.
My understanding of the meaning of that is
On Wed, Jan 19, 2011 at 8:57 PM, Noah Misch n...@leadboat.com wrote:
I think Simon was referring to the proof-of-concept sketch I had included with
my review.
I think it's a bit late to be turning proofs-of-concept into code at
this point, no matter who came up with them.
--
Robert Haas
On Wed, 2011-01-19 at 21:01 -0500, Robert Haas wrote:
On Wed, Jan 19, 2011 at 8:57 PM, Noah Misch n...@leadboat.com wrote:
I think Simon was referring to the proof-of-concept sketch I had included
with
my review.
I think it's a bit late to be turning proofs-of-concept into code at
this
On Wed, Jan 19, 2011 at 9:44 PM, Simon Riggs si...@2ndquadrant.com wrote:
Noah's patch is trivial, as are the changes to make mine work fully.
I dispute that. In particular:
+ /*
+* Exchange table contents
+*
+* Swap heaps, toast tables, toast indexes
+*
On Tue, 2010-12-14 at 19:48 +, Simon Riggs wrote:
On Tue, 2010-12-14 at 11:34 -0800, Josh Berkus wrote:
As for the utility of this command: there is no question that I would
use it. I'm not sure I like the syntax (I'd prefer REPLACE TABLE
WITH _), but that's painting the bike
On Wed, Dec 15, 2010 at 2:39 AM, Simon Riggs si...@2ndquadrant.com wrote:
Perhaps a more useful definition would be
EXCHANGE TABLE target WITH source;
which just swaps the heap and indexes of each table.
At the risk of stating the obvious, this would work with partition exchange too?
--
On Thu, 2010-12-16 at 16:19 -0800, bricklen wrote:
On Wed, Dec 15, 2010 at 2:39 AM, Simon Riggs si...@2ndquadrant.com wrote:
Perhaps a more useful definition would be
EXCHANGE TABLE target WITH source;
which just swaps the heap and indexes of each table.
At the risk of stating the
On Wed, 2010-12-15 at 10:54 +0100, Csaba Nagy wrote:
On Tue, 2010-12-14 at 14:36 -0500, Robert Haas wrote:
Well, you have to do that for DROP TABLE as well, and I don't see any
way around doing it for REPLACE WITH.
Sure, but in Simon's proposal you can load the data FIRST and then
On Wed, Dec 15, 2010 at 5:39 AM, Simon Riggs si...@2ndquadrant.com wrote:
Perhaps a more useful definition would be
EXCHANGE TABLE target WITH source;
which just swaps the heap and indexes of each table.
You can then use TRUNCATE if you want to actually destroy data.
I will go with that
On Dec 15, 2010, at 4:39 AM, Simon Riggs wrote:
On Wed, 2010-12-15 at 10:54 +0100, Csaba Nagy wrote:
On Tue, 2010-12-14 at 14:36 -0500, Robert Haas wrote:
Well, you have to do that for DROP TABLE as well, and I don't see any
way around doing it for REPLACE WITH.
Sure, but in Simon's
On Wed, 2010-12-15 at 10:39 +, Simon Riggs wrote:
Perhaps a more useful definition would be
EXCHANGE TABLE target WITH source;
which just swaps the heap and indexes of each table.
You can then use TRUNCATE if you want to actually destroy data.
Yes please, that's exactly what I would
On Tue, 2010-12-14 at 14:36 -0500, Robert Haas wrote:
Well, you have to do that for DROP TABLE as well, and I don't see any
way around doing it for REPLACE WITH.
Sure, but in Simon's proposal you can load the data FIRST and then
take a lock just long enough to do the swap. That's very
On Wed, 2010-12-15 at 07:43 -0600, David Christensen wrote:
Are there any considerations with toast tables and the inline line pointers
for toasted tuples?
Toast tables would be swapped as well. Toast pointers are only
applicable within a relfilenode, so we could not do otherwise.
--
Simon
On Wed, 2010-12-15 at 12:17 +0100, Csaba Nagy wrote:
But one problem would be when the replaced table is the _parent_ for a
foreign key relationship. I don't think you can have that constraint
pre-verified on the replacement table and simply replacing the content
could leave the child
On Wed, Dec 15, 2010 at 11:30 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Heikki Linnakangas wrote:
On 14.12.2010 20:27, Simon Riggs wrote:
1. Prepare new data into new_table and build indexes
2. Swap old for new
BEGIN;
DROP TABLE old_table;
ALTER TABLE new_table RENAME to
On Wed, Dec 15, 2010 at 10:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-12-15 at 12:17 +0100, Csaba Nagy wrote:
But one problem would be when the replaced table is the _parent_ for a
foreign key relationship. I don't think you can have that constraint
pre-verified on the
Heikki Linnakangas wrote:
On 14.12.2010 20:27, Simon Riggs wrote:
1. Prepare new data into new_table and build indexes
2. Swap old for new
BEGIN;
DROP TABLE old_table;
ALTER TABLE new_table RENAME to old_table;
COMMIT;
Step (2) works, but any people queuing to access the table
will
There are various applications where we want to completely replace the
contents of a table with new/re-calculated data.
It seems fairly obvious to be able to do this like...
1. Prepare new data into new_table and build indexes
2. Swap old for new
BEGIN;
DROP TABLE old_table;
ALTER TABLE
Simon Riggs si...@2ndquadrant.com writes:
There are various applications where we want to completely replace the
contents of a table with new/re-calculated data.
It seems fairly obvious to be able to do this like...
1. Prepare new data into new_table and build indexes
2. Swap old for new
On Tue, 2010-12-14 at 13:54 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
There are various applications where we want to completely replace the
contents of a table with new/re-calculated data.
It seems fairly obvious to be able to do this like...
1. Prepare new data
On Tue, Dec 14, 2010 at 1:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BEGIN;
TRUNCATE TABLE;
... load new data ...
COMMIT;
Because then you have to take an AccessExclusiveLock on the target
table, of course.
If we had some kind of TRUNCATE CONCURRENTLY, I think that'd address a
large portion
On 12/14/10 11:07 AM, Robert Haas wrote:
Because then you have to take an AccessExclusiveLock on the target
table, of course.
Well, you have to do that for DROP TABLE as well, and I don't see any
way around doing it for REPLACE WITH.
As for the utility of this command: there is no question
On 14.12.2010 20:27, Simon Riggs wrote:
There are various applications where we want to completely replace the
contents of a table with new/re-calculated data.
It seems fairly obvious to be able to do this like...
1. Prepare new data into new_table and build indexes
2. Swap old for new
BEGIN;
On Tue, Dec 14, 2010 at 2:34 PM, Josh Berkus j...@agliodbs.com wrote:
On 12/14/10 11:07 AM, Robert Haas wrote:
Because then you have to take an AccessExclusiveLock on the target
table, of course.
Well, you have to do that for DROP TABLE as well, and I don't see any
way around doing it for
On Tue, 2010-12-14 at 21:35 +0200, Heikki Linnakangas wrote:
On 14.12.2010 20:27, Simon Riggs wrote:
There are various applications where we want to completely replace the
contents of a table with new/re-calculated data.
It seems fairly obvious to be able to do this like...
1. Prepare
On Tue, 2010-12-14 at 11:34 -0800, Josh Berkus wrote:
In order for REPLACE WITH to be really useful, though, we need a
command cloning at table design with *all* constraints, FKs, keys, and
indexes. Currently, I still don't think we have that ... do we?
Being able to vary the indexes when
On Tue, 2010-12-14 at 11:34 -0800, Josh Berkus wrote:
As for the utility of this command: there is no question that I would
use it. I'm not sure I like the syntax (I'd prefer REPLACE TABLE
WITH _), but that's painting the bike shed.
REPLACE TABLE ying WITH yang
is probably easier to
On Tue, 2010-12-14 at 16:19 -0800, Josh Berkus wrote:
Without some means of doing a clone of the table in a single command,
you've eliminated half the scripting work, but not helped at all with
the other half.
I'm not trying to eliminate scripting work, I'm trying to minimise the
lock window
On 12/14/10 11:43 AM, Simon Riggs wrote:
On Tue, 2010-12-14 at 11:34 -0800, Josh Berkus wrote:
In order for REPLACE WITH to be really useful, though, we need a
command cloning at table design with *all* constraints, FKs, keys, and
indexes. Currently, I still don't think we have that ... do
I have; the above would hold the lock window open while the SELECT runs
and that is explicitly something we are trying to avoid.
Not necessarily. You could copy into a temp table first, and then swap.
--
-- Josh Berkus
45 matches
Mail list logo
