How to controll the name of partition column

Community Support
1

Partitioned table are usually partitioned by date. In my case, I would like to create partitions by interger.
I start with table with one partiton (value 999):

`:/db/999/t/ set ( dt:2008.01.01 2008.01.02; p:101 102f)

After load and select | can see, there is a column with name “int”, fine. I insert next two rows into partition 1000.

`:/db/1000/t/ set ( dt:2009.01.01 2009.01.02; p:101.5 102.5)

After select, I can see, that “int” column has new name “year”. Is there a way, how to make the partition column name invariable?

Thanks, Pavel

 

2

I think you could use the range 10000 thru 999999.

It determines the field in .Q.L, from the length of the first entry returned from key`:/db

I don’t think leading zeros (e.g. 00100) will fully work.

3

Thank you, Charles! First entry by which order? According to my example I know, it is not asc order of partiton value.
I couldn’t find doc for .Q.L, but fortunately, the k code is self-explanatory (:
{D::();if[x~,par.txt;if[~#x:,/D::!:'P::$“:”,‘0:*x;‘empty]];if[^*PV::x@:\<x:(t:"DMJJ"i:10 7 4?#$*x)$$x;'part]
 PD::$[#D::t$’$D;,/{P@&x in’D}’?PV;(#PV)#`:.];pf::`date`month`year`int i;view;if[(0>.“\p”)|.“\_”;cn’.:'pt];}

Dne úterý, 27. kv?tna 2014 13:45:39 UTC+2 Charles Skelton napsal(a):

I think you could use the range 10000 thru 999999.

It determines the field in .Q.L, from the length of the first entry returned from key`:/db

I don’t think leading zeros (e.g. 00100) will fully work.

4

q)key`:.

s#1000`999

so it takes the first entry, 1000 and matches it with year.

relevant code is

"DMJJ"i:10 7 4?#$*x / find in 10 7 4 the count of string of first of x

if you get stuck with these things, try inserting debug to show you what’s going on, e.g.

t:"DMJJ"i:10 7 4?#$*0N!x) / see http://code.kx.com/wiki/Reference/BangSymbol

partition field is set using the result from the above

pf::datemonthyearint i

q)`:db/999/t/ set ( dt:2008.01.01 2008.01.02; p:101 102f)

`:db/999/t/

q)\l db

q)t

int dt         p  

999 2008.01.01 101

999 2008.01.02 102

q)`:../db/1000/t/ set ( dt:2008.01.01 2008.01.02; p:101 102f)

`:../db/1000/t/

q)\l .

q)t

year dt         p  

999  2008.01.01 101

999  2008.01.02 102

1000 2008.01.01 101

1000 2008.01.02 102

q)key`:.

s#1000`999

q)\

5

Interesting.

Charles, I would just like to understand kx/Arthurs’ logic here as I assume you have been thorough all paths and had to end up at this method. The only problem I have with this is as we increase our db size over the years, and the partition frequency slowly increases I can only see integer partitions becoming more popular. This in essence says we cant partition with an integer of 4 digits…is that correct?

What was the reason for using this method rather than say;

  1. save hdb out using partition type so 2014.05 m , 2014.04 m instead of 2014.05, 2014.04, and then this could be implemented for all types also. This could then be used for “i”, “m”, “d” etc, and possibly “y” if you changed year to include a type. Even “u” could be included but I can’t think of a use case for this!! The only change that would be have to be made is what you said "DMJJ"i:10 7 4?#$*x…changed to a like “i” or like “m”, and the save functions(probably a few more not mentioned). One downfall with this I guess is compatibility, but maybe you already have plans??

Just curious that’s all,

Sean

6

I think this is the first time I’ve seen an issue with int partitions. With 64bit, of course there’s little reason to be concerned, but 32bit is forcing users to consider large numbers of partitions, and I’ve already given what I believe is a solution.