The Vertica Database Forums

Hi!

Probably local resegmentation takes a time:

Locally Resegment By: ((((((100 \<*\> 69069) \<+\> internal_strhash(a.storid)) \<*\> 69069) \<+\> internal_numhash(a.tempid)) \<*\> 69069) \<+\> a.tempid1)

Why you have segmentation on one node?
More interesting why Vertica performs resegmentation? 'internal_numhash' and 'internal_strhash' - its UDF or SQL functions? Are they stable, immutable?

The table creation script is common for both clustered and single node.(using the segmenation clause for both)

How does that affect partition pruning

If the table creation steps are identical on both clusters, you should be getting partition pruning on both clusters. If you are able to provide an actual example we may be able to offer more insight. Or open a support case.

--Sharon

I'm reminded that in 6.x you can get partition pruning info from the query_events table. No need to use the undocumented "old school" explain method.

event_type | PARTITIONS_ELIMINATED
event_description | Some storage containers will not be processed because they contain no relevant data.
event_details | Using only 0 stores out of 7 for projection public.tpart_super

Hi!

@Sharon
More interesting its - why Vertica do a re-segmentation when 0 rows deleted (doesn't matter if a partition pruning occurred or not, even if it occurred Vertica should not to do a re-segmentation) ?

I think that resegmentation in this context is referring to resegmentation within a node for the purpose of further parallelizing work. For example for a GROUP BY you may see LOCAL RESEGMENT in the explain plan. GLOBAL RESEGMENT goes across nodes.