djk447

9 ms·

1. 61.▲
   by djk447 6y ago

   (Just noticed this was about dump/restore, during restores you can in fact write the data and then build the index in a separate operation and that can be faster, sorry for missing context)
2. 62.▲
   by djk447 6y ago

   I mean, I'm not sure this is the place to get into detailed schema discussions, but I think I wouldn't use a row_id here at all, certainly, there's no need for this to be unique across all of the rows, you could make a unique
3. 63.▲
   by djk447 6y ago

   Sorry, the previous reply suggested it was on row_id, time I thought, anyway. I think the question is why should row_id be unique? What looks it up by row_id? And can they look it up by user_id/time instead? It may be impossible. On th
4. 64.▲
   by djk447 6y ago

   Why not create an index on user_id, time? Why do you need a unique reference back to the row? We find that they're often (though certainly not always) kind of meaningless and/or unnecessary for timeseries workloads.
5. 65.▲
   by djk447 6y ago

   Indexes are built during the inserts for copies and for normal inserts, in general copies are faster because many people use single row inserts that need to instantiate executor nodes and other bits for every row. I think there used to be s
6. 66.▲
   by djk447 7y ago

   Hi! Engineer at Timescale who’s just been working on this feature, it’s coming in our next release and going to continue to be developed over the next few releases! Would love to have you try it out and get your feedback :)