timescaledb icon indicating copy to clipboard operation
timescaledb copied to clipboard

add offset and origin options to time_bucket_gapfill

Open mmouterde opened this issue 6 years ago • 25 comments

Relevant system information:

  • TimescaleDB version : 1.3.0

Describe the bug

  • I'm using time_bucket function with the offset option.
  • I would like to use the new gapfilling feature but the offset option is not provided.
  • I can't benefit from the gapfilling feature without regressions.

Expected behavior time_bucket_gapfill takes an offset option

mmouterde avatar Jun 20 '19 15:06 mmouterde

Thank you for requesting the feature. We will followup.

k-rus avatar Jun 21 '19 08:06 k-rus

Origin should be implemented as well, it's hard to use the gapfilling features without origin and offset since the data being aggregated isn't even within the range you essentially query for, but instead is seemingly the closest multiple of the bucket size from the start time and on...

allstream avatar Mar 09 '20 19:03 allstream

instead is seemingly the closest multiple of the bucket size from the start time and on...

Could you elaborate what you mean here?

And does anyone have any workarounds at the moment to implement this feature? Like could you get feature parity by tuning your query parameters and dealing with it on the client?

ricky-sb avatar Mar 25 '20 21:03 ricky-sb

Hi everyone, is this already on the roadmap?

Thanks!

PhilippS93 avatar Dec 15 '20 09:12 PhilippS93

I spent too much time today trying to achieve this with the workaround mentioned in #1545, but it is too complicated (we also need to interpolate). Initially I expected that the start parameter would be enough, so I think this behavior should be mentioned in the time_bucket_gapfill documentation.

ateuber avatar Feb 23 '21 18:02 ateuber

Can we have this on the roadmap I also spent half a day before realizing why all my days were wrong :(

Sytten avatar Mar 23 '21 02:03 Sytten

it's a big API inconsistency since one would naturally expect time_bucket and time_bucket_gapfill to have similar behaviour everywhere else apart from the gap-filling itself.

eloyekunle avatar May 11 '21 11:05 eloyekunle

Is there a way to find out whether this issue is going to be addressed?

brakonstantin avatar Jul 29 '21 11:07 brakonstantin

Hello @brakonstantin, we coordinate our efforts based on our community votes. Here are the latest priorities. Please upvote to help us to prioritize it in the next months.

jonatas avatar Jul 29 '21 13:07 jonatas

This would be awesome!

diego-escobedo avatar Dec 22 '22 05:12 diego-escobedo

This would be very useful

aorticweb avatar Jan 10 '23 10:01 aorticweb

This would be very useful!

tomasrosauer avatar Jan 10 '23 13:01 tomasrosauer

I need this so much right now :100:!! Any updates on this?

luislvasquez avatar Jan 10 '23 13:01 luislvasquez

This would be awesome!

Rayman-katib avatar Jan 10 '23 18:01 Rayman-katib

I'm also missing this feature.

jontingvold avatar Feb 23 '23 10:02 jontingvold

+1, Would be great

melicheradam avatar Aug 21 '23 10:08 melicheradam

+1, this would be very handy

zaycev avatar Sep 06 '23 13:09 zaycev

is there any update on this issue? been open since 2019 and without the "origin" parameter the time_bucket_gapfill function is effectively useless as it does not align with the requested datetime period.

aabrodskiy avatar Apr 25 '24 19:04 aabrodskiy

Please make it real!

miguetronic avatar Apr 26 '24 21:04 miguetronic

Origin

Absolutely. We need the same fix for offset and origin to make time_bucket_gapfill work. Without these fixes, we are stuck writing the same function with the fixes, but without the performance and confidence of longevity.

MichaelSaucier avatar May 20 '24 15:05 MichaelSaucier