Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can't make partitioning on custom type column #470

Closed
the20login opened this issue Mar 16, 2018 · 5 comments
Closed

Can't make partitioning on custom type column #470

the20login opened this issue Mar 16, 2018 · 5 comments
Labels
bug

Comments

@the20login
Copy link

I've got two columns on which I would like to make subpartitioning. Since timescale supports only one level subpatitioning, I start thinking about custom type. However 'create_hypertable' gives me an error even if I define custom 'partitioning_func'.
As far as I understand, partitioning_func result should be used for hashing/choosing chunk, not original column value, which mean that if 'partitioning_func' is defined, type check should be ommited.

CREATE TYPE composite as (val1 int4, val2 int4);
CREATE FUNCTION composite_type_hash(value ANYELEMENT) RETURNS INT4 /*--some implementation--*/
CREATE TABLE timescale_history ("timestamp" TIMESTAMPTZ, object composite, value TEXT);
SELECT create_hypertable('timescale_history', 'timestamp', 'object', 1000, '1 day', partitioning_func=>'composite_type_hash');

results
ERROR: could not find hash function for type 72761
@cevian
Copy link
Contributor

cevian commented Mar 16, 2018

@the20login We'll take a look at this issue. But I wanted to point out that we do support multi-column/level subpartitioning through add_dimension (https://docs.timescale.com/v0.9/api#add_dimension).

@the20login
Copy link
Author

Didn't notice it, my mistake.
Thanks for the tip.

@cevian cevian closed this as completed Mar 28, 2018
@the20login
Copy link
Author

Why it is closed? Yes, I personally didn't use this functionality, but the bug is still there.

@cevian
Copy link
Contributor

cevian commented Mar 29, 2018

Oh yes you are right! Thank you.

@cevian cevian reopened this Mar 29, 2018
@mfreed mfreed added the bug label Apr 3, 2018
@JLockerman
Copy link
Contributor

Some notes as I debug this:

The specific error is from src/partitioning.c:167

Backtrace:

frame #0: partitioning_info_create(schema="public", partfunc=<unavailable>, partcol=<unavailable>, relid=<unavailable>) at partitioning.c:167
frame #1: dimension_tuple_found at dimension.c:145
frame #2: dimension_tuple_found(ti=<unavailable>, data=<unavailable>) at dimension.c:311
frame #3: scanner_scan(ctx=0x00007ffee3fb5950) at scanner.c:208
frame #4: dimension_scan [inlined] dimension_scan_internal(nkeys=1) at dimension.c:339
frame #5: dimension_scan(hypertable_id=1, main_table_relid=<unavailable>, num_dimensions=2, mctx=0x00007fc314035258) at dimension.c:352
frame #6: hypertable_from_tuple(tuple=0x00007fc31404e070, mctx=0x00007fc314035258) at hypertable.c:92
frame #7: hypertable_tuple_found(ti=<unavailable>, data=0x00007fc31384b910) at hypertable_cache.c:75
frame #8: scanner_scan(ctx=0x00007ffee3fb5b68) at scanner.c:208
frame #9: hypertable_tuple_found at hypertable_cache.c:72), scandata=0x00007fc31384b910, limit=1, lock=1, tuplock='\0', mctx=0x00007fc314035258) at hypertable.c:180
frame #10: hypertable_tuple_found at hypertable_cache.c:72), data=0x00007fc31384b910, lockmode=1, tuplock='\0', mctx=0x00007fc314035258) at hypertable.c:249
frame #11: hypertable_cache_create_entry(cache=0x00007fc31386be40, query=0x00007ffee3fb5dc0) at hypertable_cache.c:92
frame #12: cache_fetch(cache=0x00007fc31386be40, query=0x00007ffee3fb5dc0) at cache.c:0
frame #13: hypertable_cache_get_entry [inlined] hypertable_cache_get_entry_with_table(cache=<unavailable>, relid=<unavailable>) at hypertable_cache.c:155
frame #14: hypertable_cache_get_entry(cache=<unavailable>, relid=<unavailable>) at hypertable_cache.c:132
frame #15: hypertable_create(fcinfo=<unavailable>) at hypertable.c:1067

@Ngalstyan4 Ngalstyan4 mentioned this issue Aug 2, 2018
Merged
Ngalstyan4 added a commit to Ngalstyan4/timescaledb that referenced this issue Aug 6, 2018
@Ngalstyan4
Add support for custom hypertable dimension types
c3d58ee 
Previously, if a hypertable dimension type did not have a default
hash function, create_hypertable would throw an error.
However, this should not be the case if a custom partitioning
function is provided.
This commit addresses the issue making sure that arbitrary
custom types can be used as partitioning dimensions as long
as a valid partitioning function is provided.
Fixes timescale#470.
RobAtticus pushed a commit that referenced this issue Aug 6, 2018
@Ngalstyan4 @RobAtticus
Add support for custom hypertable dimension types
a97f2af 
Previously, if a hypertable dimension type did not have a default
hash function, create_hypertable would throw an error.
However, this should not be the case if a custom partitioning
function is provided.
This commit addresses the issue making sure that arbitrary
custom types can be used as partitioning dimensions as long
as a valid partitioning function is provided.
Fixes #470.
syvb pushed a commit to syvb/timescaledb that referenced this issue Sep 8, 2022
@bors @rtwalker
Merge timescale#470
b921ff4 
470: update cargo.lock to match cargo.toml r=rtwalker a=rtwalker

Should have been included as part of timescale#461 

Co-authored-by: Ryan Walker <rwalker@timescale.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cevian @mfreed @the20login @JLockerman