On Tue, May 3, 2011 at 4:54 PM, Tom Lane wrote:
> Simon Riggs writes:
>> You're assuming that there are referential links *from* other tables
>> to the table with damage. In which case you would be correct. But of
>> course, if you needed that data for integrity you would never do that,
>> so the
Simon Riggs writes:
> You're assuming that there are referential links *from* other tables
> to the table with damage. In which case you would be correct. But of
> course, if you needed that data for integrity you would never do that,
> so the problem is a nonexistent use case. The suggested mode
On Tue, May 3, 2011 at 8:21 PM, Simon Riggs wrote:
> The current assessment is that UNLOGGED tables are useful only for
> running a data cache. If the database crashes, then the table is
> truncated and you must refill the cache. If that is the case, then it
> must surely be better to have a cache
On Tue, Apr 26, 2011 at 8:49 AM, Leonardo Francalanci wrote:
>> > If that 1% is random (not time/transaction related), usually you'd rather
>>have an empty table.
>>
>> Why do you think it would be random?
>
> "Heap blocks would be zeroed if they were found to be damaged, following a
> crash."
>
2011/4/25 Christopher Browne :
> On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh wrote:
>> On 2011-04-25 20:00, Leonardo Francalanci wrote:
The amount of data loss on a big table will be <1% of the data
loss caused by truncating the whole table.
>>>
>>> If that 1% is random (not time/trans
> > If that 1% is random (not time/transaction related), usually you'd rather
>have an empty table.
>
> Why do you think it would be random?
"Heap blocks would be zeroed if they were found to be damaged, following a
crash."
If you erase full blocks, you have no idea what data you erased; it
Robert Haas writes:
> However, I think that the "logged table, unlogged index" idea is
> probably the most promising thing to think about doing first.
+1 for that --- it's clean, has a clear use-case, and would allow us
to manage the current mess around hash indexes more cleanly.
That is, hash in
On Mon, Apr 25, 2011 at 2:21 PM, Simon Riggs wrote:
>> Right, but the trick is how you identify which blocks you need to
>> zero. You used the word "damaged", which to me implied that the block
>> had been modified in some way but ended up with other than the
>> expected contents, so that somethi
On Mon, Apr 25, 2011 at 1:42 PM, Robert Haas wrote:
> On Mon, Apr 25, 2011 at 5:04 AM, Simon Riggs wrote:
>> On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas wrote:
>>> On Apr 24, 2011, at 1:22 PM, Simon Riggs wrote:
Unlogged tables are a good new feature.
>>>
>>> Thanks.
>>>
I noticed Br
On Mon, Apr 25, 2011 at 7:00 PM, Leonardo Francalanci wrote:
>> The amount of data loss on a big
>> table will be <1% of the data loss
>>caused by truncating the whole table.
>
> If that 1% is random (not time/transaction related), usually you'd rather
> have an empty table.
Why do you think it
On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh wrote:
> On 2011-04-25 20:00, Leonardo Francalanci wrote:
>>> The amount of data loss on a big table will be <1% of the data
>>> loss caused by truncating the whole table.
>>
>> If that 1% is random (not time/transaction related), usually you'd
>> rath
Jesper Krogh wrote:
> On 2011-04-25 20:00, Leonardo Francalanci wrote:
>>> The amount of data loss on a big table will be <1% of the data
>>> loss caused by truncating the whole table.
>>
>> If that 1% is random (not time/transaction related), usually
>> you'd rather have an empty table. In othe
On 2011-04-25 20:00, Leonardo Francalanci wrote:
> The amount of data loss on a big table will be <1% of the data
> loss caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd
rather have an empty table. In other words: is a table that is not
> The amount of data loss on a big
> table will be <1% of the data loss
>caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd rather have
an empty table. In other words: is a table that is not consistant with anything
else in the db useful?
--
On Mon, Apr 25, 2011 at 3:36 AM, Leonardo Francalanci wrote:
> The only data we can't rebuild it's the heap. So what about an option for
> UNlogged indexes on a LOGged table? It would always preserve data, and it
> would 'only' cost a rebuilding of the indexes in case of an unclean shutdown.
>
On Mon, Apr 25, 2011 at 5:04 AM, Simon Riggs wrote:
> On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas wrote:
>> On Apr 24, 2011, at 1:22 PM, Simon Riggs wrote:
>>> Unlogged tables are a good new feature.
>>
>> Thanks.
>>
>>> I noticed Bruce had mentioned they were the equivalent of NoSQL, which
>>>
On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas wrote:
> On Apr 24, 2011, at 1:22 PM, Simon Riggs wrote:
>> Unlogged tables are a good new feature.
>
> Thanks.
>
>> I noticed Bruce had mentioned they were the equivalent of NoSQL, which
>> I don't really accept.
>
> Me neither. I thought that was poo
On Mon, Apr 25, 2011 at 8:36 AM, Leonardo Francalanci wrote:
> The only data we can't rebuild it's the heap. So what about an option for
> UNlogged indexes on a LOGged table? It would always preserve data, and it
> would 'only' cost a rebuilding of the indexes in case of an unclean shutdown.
>
The only data we can't rebuild it's the heap. So what about an option for
UNlogged indexes on a LOGged table? It would always preserve data, and it would
'only' cost a rebuilding of the indexes in case of an unclean shutdown. I think
it would give a boost in performance for all those cases where
On Apr 24, 2011, at 1:22 PM, Simon Riggs wrote:
> Unlogged tables are a good new feature.
Thanks.
> I noticed Bruce had mentioned they were the equivalent of NoSQL, which
> I don't really accept.
Me neither. I thought that was poorly said.
> Heap blocks would be zeroed if they were found to be
On Sun, Apr 24, 2011 at 11:15 PM, Simon Riggs wrote:
> IMHO deleting all the data is a surprising option that will
> cause many people to curse us. I don't see preserving some of the data
> as being worse.
What possible damage to you want to recover from?
Without WAL logging after a software cra
On Sun, Apr 24, 2011 at 7:41 PM, Greg Stark wrote:
> On Sun, Apr 24, 2011 at 6:22 PM, Simon Riggs wrote:
>> My implementation path for that would be to add a crash_number onto
>> pg_control and pg_index. Any index marked as "unlogged, persistent"
>> would only be usable if it's crash number is th
On Sun, Apr 24, 2011 at 6:15 PM, Simon Riggs wrote:
> For large sets of low value data, it makes sense. Deleting all data,
> just simply because some of it might be damaged, is not the only
> option. IMHO deleting all the data is a surprising option that will
> cause many people to curse us. I don
On Sun, Apr 24, 2011 at 10:27 PM, Tom Lane wrote:
> Simon Riggs writes:
>> If you don't log changes to tables you have two choices if we crash
>> 1) truncate the table and any indexes
>> 2) rebuild any indexes damaged by the crash
>
> No, you have only one choice, and that's (1), because there's
Simon Riggs writes:
> If you don't log changes to tables you have two choices if we crash
> 1) truncate the table and any indexes
> 2) rebuild any indexes damaged by the crash
No, you have only one choice, and that's (1), because there's no
guarantee that what's in the table file is meaningful.
On Sun, Apr 24, 2011 at 6:22 PM, Simon Riggs wrote:
> My implementation path for that would be to add a crash_number onto
> pg_control and pg_index. Any index marked as "unlogged, persistent"
> would only be usable if it's crash number is the same as current
> system crash number.
>
> REINDEX woul
Unlogged tables are a good new feature.
I noticed Bruce had mentioned they were the equivalent of NoSQL, which
I don't really accept. I guess it depends upon whether you mean NoSQL
for caches (e.g. memcached) or NoSQL for useful datastores (e.g.
Mongo). It seems worth discussin now before we get t
27 matches
Mail list logo
