Hi, I would agree that there may be threading happening but the explanation plan says: explain select 1+1; Access Path: +-STORAGE ACCESS for dual [Cost: 663, Rows: 10K (NO STATISTICS)] (PATH ID: 1) | Projection: v_catalog.dual_p | Materialize: dual.dummy | Execute on: Query Initiator I'm not sure ho...

Maybe I didn't explain my confusion very well: db=> profile select 1+1; NOTICE: Statement is being profiled. HINT: select * from v_monitor.execution_engine_profiles where transaction_id=45035996340493973 and statement_id=3; NOTICE: Initiator memory for query: [on pool sysquery: 4232 KB, minimum: 423...

Hi, I'm using Vertica V5.0.12 and trying to optimize some queries. I am seeing wild variation between successive profile runs of exactly the same query and I am having trouble resolving the timing result printed from vsql against the timing numbers that the execution_engine_profiles table reports: V...

Fantastic, thanks very much!

Allan

Hi,

I created a projection but have forgotten what it was and stupidly never wrote it down. Now I'd like to document it and use it in a another identical database. I can't seem to find anything in the manual that reveals the structure of a projection, does anyone know if this is possible?

Allan

Hi,

thanks for that, unfortunately we're not using 6.x (yet), so I'll do it the long way with temporary tables.

Allan

knicely87 wrote:Becky,

Unfortunately for now, you'll have to separate the two column updates using similar sub-queries.

What if the sub-queries are expensive, e.g. from a SELECT statement? Is there any workaround to avoid executing the SELECT for each column?

Thanks,

Allan