> 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
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 negative behaviour for the first
reader.
18 matches
Mail list logo
