> Simon Riggs wrote:
> Kevin Grittner wrote:
>> Simon Riggs wrote:
>>
>>> I like Marti's idea. At present, making his idea work could
>>> easily mean checksums sink
>> For my part, improving bulk load performance and TRUNCATE
>> transactional semantics would trump checksums
> It doesn't look
On Fri, Mar 2, 2012 at 11:15 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> I like Marti's idea. At present, making his idea work could easily
>> mean checksums sink, so not sure whether to attempt to make that
>> work in detail.
>
> For my part, improving bulk load performance and TRUNCATE
On Sat, Mar 3, 2012 at 1:14 PM, Simon Riggs wrote:
> On Fri, Mar 2, 2012 at 8:58 PM, Noah Misch wrote:
>> On Fri, Mar 02, 2012 at 08:46:45AM +, Simon Riggs wrote:
>>> On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas
>>> wrote:
>>> > It's still broken:
>>
>> [BEGIN;TRUNCATE;SAVEPOINT;COPY;
On Fri, Mar 2, 2012 at 8:58 PM, Noah Misch wrote:
> On Fri, Mar 02, 2012 at 08:46:45AM +, Simon Riggs wrote:
>> On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas
>> wrote:
>> > It's still broken:
>
> [BEGIN;TRUNCATE;SAVEPOINT;COPY;ROLLBACK TO]
>
>> So this approach isn't the one...
>>
>> Th
Simon Riggs wrote:
> I like Marti's idea. At present, making his idea work could easily
> mean checksums sink, so not sure whether to attempt to make that
> work in detail.
For my part, improving bulk load performance and TRUNCATE
transactional semantics would trump checksums. If we have to d
On Fri, Mar 2, 2012 at 8:58 PM, Noah Misch wrote:
> On Fri, Mar 02, 2012 at 08:46:45AM +, Simon Riggs wrote:
>> On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas
>> wrote:
>> > It's still broken:
>
> [BEGIN;TRUNCATE;SAVEPOINT;COPY;ROLLBACK TO]
>
>> So this approach isn't the one...
>>
>> Th
Noah Misch wrote:
> Incidentally, I contend that we should write frozen tuples to
> new/truncated tables unconditionally.
+1
> The current behavior of making old snapshots see the table as
> empty violates atomicity at least as badly as letting those
> snapshots see the future-snapshot cont
On Fri, Mar 02, 2012 at 08:46:45AM +, Simon Riggs wrote:
> On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas
> wrote:
> > It's still broken:
[BEGIN;TRUNCATE;SAVEPOINT;COPY;ROLLBACK TO]
> So this approach isn't the one...
>
> The COPY FREEZE patch provides a way for the user to say explici
On Thu, Mar 1, 2012 at 8:49 PM, Heikki Linnakangas
wrote:
> On 01.03.2012 18:40, Simon Riggs wrote:
>>
>> On Sun, Feb 26, 2012 at 7:16 PM, Heikki Linnakangas
>> wrote:
>>>
>>> On 24.02.2012 22:55, Simon Riggs wrote:
What exactly does it do? Previously, we optimised COPY when it wa
On 01.03.2012 18:40, Simon Riggs wrote:
On Sun, Feb 26, 2012 at 7:16 PM, Heikki Linnakangas
wrote:
On 24.02.2012 22:55, Simon Riggs wrote:
What exactly does it do? Previously, we optimised COPY when it was
loading data into a newly created table or a freshly truncated table.
This patch exten
On Sun, Feb 26, 2012 at 7:16 PM, Heikki Linnakangas
wrote:
> On 24.02.2012 22:55, Simon Riggs wrote:
>>
>> A long time ago, in a galaxy far away, we discussed ways to speed up
>> data loads/COPY.
>> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00470.php
>>
>> In particular, the idea tha
On Wed, Feb 29, 2012 at 6:14 PM, Christopher Browne wrote:
> On Wed, Feb 29, 2012 at 11:14 AM, Simon Riggs wrote:
>> But it is very effective at avoiding 4 out of the 5 writes you mention.
>
> For the "common case," would we not want to have (1) [WAL] and (2)
> [Writing the pre-frozen tuple]?
>
>
On Wed, Feb 29, 2012 at 11:14 AM, Simon Riggs wrote:
> But it is very effective at avoiding 4 out of the 5 writes you mention.
For the "common case," would we not want to have (1) [WAL] and (2)
[Writing the pre-frozen tuple]?
If we only write the tuple (2), and don't capture WAL, then the COPY
w
On Sat, Feb 25, 2012 at 6:58 PM, Simon Riggs wrote:
> On Sat, Feb 25, 2012 at 6:24 PM, Kevin Grittner
> wrote:
>> Simon Riggs wrote:
>>
>>> This patch extends that and actually sets the tuple header flag as
>>> HEAP_XMIN_COMMITTED during the load.
>>
>> Fantastic!
> I think we could add that as
On 24.02.2012 22:55, Simon Riggs wrote:
A long time ago, in a galaxy far away, we discussed ways to speed up
data loads/COPY.
http://archives.postgresql.org/pgsql-hackers/2007-01/msg00470.php
In particular, the idea that we could mark tuples as committed while
we are still loading them, to avoid
On Sat, Feb 25, 2012 at 6:24 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> This patch extends that and actually sets the tuple header flag as
>> HEAP_XMIN_COMMITTED during the load.
>
> Fantastic!
>
> So, without bulk-load conditions, a long-lived tuple in PostgreSQL
> is written to disk at
Simon Riggs wrote:
> This patch extends that and actually sets the tuple header flag as
> HEAP_XMIN_COMMITTED during the load.
Fantastic!
So, without bulk-load conditions, a long-lived tuple in PostgreSQL
is written to disk at least five times[1]:
(1) The WAL record for the inserted tuple
17 matches
Mail list logo
