Re: On partitioning - Mailing list pgsql-hackers
From | Jim Nasby |
---|---|
Subject | Re: On partitioning |
Date | |
Msg-id | 54820CE3.7030706@BlueTreble.com Whole thread Raw |
In response to | Re: On partitioning (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Responses |
Re: On partitioning
(Robert Haas <robertmhaas@gmail.com>)
|
List | pgsql-hackers |
On 12/5/14, 1:22 PM, Jim Nasby wrote: > On 12/5/14, 3:42 AM, Amit Langote wrote: >>> > I think you are right. I think in this case we need something similar >>> >to column pg_index.indexprs which is of type pg_node_tree(which >>> >seems to be already suggested by Robert). So may be we can proceed >>> >with this type and see if any one else has better idea. >> One point raised about/against pg_node_tree was the values represented therein would turn out to be too generalized tobe used with advantage during planning. But, it seems we could deserialize it in advance back to the internal form (likean array of a struct) as part of the cached relation data. This overhead would only be incurred in case of partitionedtables. Perhaps this is what Robert suggested elsewhere. > > In order to store a composite type in a catalog, we would need to have one field that has the typid of the composite, andthe field that stores the actual composite data would need to be a "dumb" varlena that stores the composite HeapTupleHeader. On further thought; if we disallow NULL as a partition boundary, we don't need a separate rowtype; we could just use theone associated with the relation itself. Presumably that would make comparing tuples to the relation list a lot easier. I was hung up on how that would work in the case of ALTER TABLE, but we'd have the same problem with using pg_node_tree:if you alter a table in such a way that *might* affect your partitioning, you have to do some kind of revalidationanyway. The other option would be to use some custom rowtype to store boundary values and have a method that can form a boundarytuple from a real one. Either way, I suspect this is better than frequently evaluating pg_node_trees. There may be one other option. If range partitions are defined in terms of an expression that is different for every partition(ie: (substr(product_key, 1, 4), date_trunc('month', sales_date))) then we could use a hash of that expression toidentify a partition. In other words, range partitioning becomes a special case of hash partitioning. I do think we needa programmatic means to identify the range of an individual partition and hash won't solve that, but the performanceof that case isn't critical so we could use pretty much whatever we wanted to there. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
pgsql-hackers by date: