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 Ser
On Thu, Jan 20, 2011 at 6:19 PM, Noah Misch 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 flexible, muc
On Thu, Jan 20, 2011 at 11:17 AM, Simon Riggs 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, which I would
Robert Haas writes:
> On Thu, Jan 20, 2011 at 4:24 PM, Tom Lane 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 rename to t;
>>
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 utili
On Thu, Jan 20, 2011 at 4:24 PM, Tom Lane wrote:
> Noah Misch 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 cle
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 behav
Noah Misch 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
begin;
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
> > compelli
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 su
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
> ato
On Wed, Jan 19, 2011 at 9:44 PM, Simon Riggs 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
+* all forks
+* a
On Wed, 2011-01-19 at 21:01 -0500, Robert Haas wrote:
> On Wed, Jan 19, 2011 at 8:57 PM, Noah Misch 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,
On Wed, Jan 19, 2011 at 8:57 PM, Noah Misch 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
EnterpriseDB: http://
On Wed, Jan 19, 2011 at 08:55:22PM -0500, Robert Haas wrote:
> On Wed, Jan 19, 2011 at 7:57 PM, 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 re
On Wed, Jan 19, 2011 at 7:57 PM, 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 move
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 a
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
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 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
On Thu, 2010-12-16 at 16:19 -0800, bricklen wrote:
> On Wed, Dec 15, 2010 at 2:39 AM, 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.
>
> At the risk of stating the obvious, th
On Wed, Dec 15, 2010 at 2:39 AM, 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.
At the risk of stating the obvious, this would work with partition exchange too?
--
Sent via pgsql-hack
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 a
On Wed, Dec 15, 2010 at 10:50 AM, Simon Riggs 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 replacement table a
On Wed, Dec 15, 2010 at 11:30 AM, Kevin Grittner
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 "old_tab
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 rela
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.
--
Simo
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 ve
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 wo
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
On Wed, Dec 15, 2010 at 5:39 AM, 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.
>
> I will go with that unless we have o
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
> 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
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
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 windo
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
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 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.
On Tue, Dec 14, 2010 at 2:34 PM, Josh Berkus 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 REPLACE WITH
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 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 th
On Tue, Dec 14, 2010 at 1:54 PM, Tom Lane 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 of the use case
On Tue, 2010-12-14 at 13:54 -0500, Tom Lane wrote:
> Simon Riggs 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_ta
Simon Riggs 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
> BEGIN;
> DROP TA
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 "new_
45 matches
Mail list logo
