Subscribe to this thread
Home - General / All posts - Radian manual: PRAGMA topic outdated
tjhb

7,248 post(s)
#03-Mar-17 01:42

The PRAGMA topic in the Radian manual needs revision.

It has not been updated for new syntax introduced in Radian 9.0.145.

Rather than the previous syntax (still in the manual):

PRAGMA ('pragma1'='...', 'pragma2'='...') ( <one or more statements> )

we now have pragmas as individual statements, terminated by their own semicolon, and no parentheses to group following statement(s):

PRAGMA ('pragma1'='...', 'pragma2'='...');

<statement>;

<statement>;

...

PRAGMA ('pragma1'='...', 'pragma3'='...');

<statement>;

<statement>;

...

Also, pragma values are now part of state for the current execution context (command window or query).

So, for a pragma value with a given name, a later assignment overrides an earlier one (that's already partly explained), and each assignment remains effective unless/until it is overridden.

But equally, the last assignment for a given pragma value persists between runs, just like previously compiled function (I would guess that pragmas pretty much are just functions).

So if we set, say,

PRAGMA ('gpgpu' = 'aggressive');

then compile and run, and now remove or comment out that PRAGMA line, before running the code again, the same 'aggressive' value will also apply for the second run, and subsequent runs. Its previous setting is still part of state for the current execution context. It will keep the same value until we change it. It would help to have a note about this.

adamw


6,911 post(s)
#03-Mar-17 06:49

Thanks a lot for the note. We will adjust the documentation.

tjhb

7,248 post(s)
#07-Mar-17 23:49

It's been adjusted now and looks really good.

There's something I don't understand, it might be just me, but I wonder if it could be expanded upon.

It's the section

Boundaries not crossed - Pragmas do not cross the boundary of a query component or an EXECUTE statement. Consider the following: ...

First, is this still correct? (I slightly suspect it might not be--or that it is perhaps only correct now for EXECUTE statements, and for SELECT statements on external datasources.) Secondly, what does it mean? Sorry if I'm just being dense!

If it is still correct, a reason why it is the case might help explain the meaning.

adamw


6,911 post(s)
#09-Mar-17 07:29

This is still the case and will very likely remain the case in the future.

A quick example.

This shows the value of the pragma:

--SQL

PRAGMA ('custom'='abc');

VALUES ('custom', PragmaValue('custom'));

This does not:

--SQL

PRAGMA ('custom'='abc');

EXECUTE [[ VALUES ('custom', PragmaValue('custom')); ]]

Two queries behave the same as EXECUTE - the second query has its own set of pragmas and will not see the pragmas from the first query.

The separation is intentional. We don't want the second query / the query in EXECUTE to rely on pragma values in the outer query - we want all such dependencies to be explicit = parameters.

tjhb

7,248 post(s)
#09-Mar-17 08:19

Thank you Adam.

I do understand for EXECUTE--which is conceptually at one remove from the current context.

But I don't understand for the other example given:

PRAGMA ('gpgpu'='none');

SELECT ... FROM [query with GPGPU computations];

Why would the SELECT statement not know or use pragma value(s) in that case? Where is the boundary, not to be crossed?

An UPDATE or INSERT query would apparently be fine here, and would know the pragma values. Both would also usually (though not always) employ SELECT as part of their syntax.

Why is that not true for a SELECT statement alone?

I hope you can see where my confusion is. I can't see it myself.

adamw


6,911 post(s)
#09-Mar-17 08:26

The SELECT statement above - right under PRAGMA - will see 'gpgpu' as 'none'. If that SELECT does some computations that can potentially go to GPGPU, they won't go to GPGPU, because the pragma turns that off.

But if that SELECT statement includes a FROM which refers to a different query *stored as a separate component*, that different query will have its own set of pragmas, and it will use GPGPU if it so desires.

tjhb

7,248 post(s)
#09-Mar-17 08:33

Our posts crossed Adam and I think I finally got it right. Cool.

I'm not sure how it should be rewritten. Maybe just changing

PRAGMA ('gpgpu'='none');

SELECT ... FROM [query with GPGPU computations];

to

PRAGMA ('gpgpu'='none');

SELECT ... FROM <query-component>;

would be enough.

(The issue is that

[query with GPGPU computations]

can also mean an inline (sub)query. But in that case, as you have confirmed, there would be no boundary, and the pragma would carry.)

adamw


6,911 post(s)
#09-Mar-17 08:41

Got it.

We'll make the description clearer, thanks for noticing.

tjhb

7,248 post(s)
#09-Mar-17 09:02

I should have looked harder at the word "component", sorry.

tjhb

7,248 post(s)
#09-Mar-17 08:23

Oh I do get it!

When the manual says

Boundaries not crossed - Pragmas do not cross the boundary of a query component or an EXECUTE statement. Consider the following:

PRAGMA ('gpgpu'='none'); 

SELECT ... FROM [query with GPGPU computations];

...

it is literally talking about a (different) query component, not a following SELECT statement.

Aaaahhh! That makes sense!

I think that paragraph needs to be rewritten to make that clear. (Probably only a few words need changing.)

(Or, frankly, it could just be left out. No one would think that pragmas would control a different query component.)

tjhb

7,248 post(s)
#11-Mar-17 19:24

I do feel silly for having misread this paragraph now. There were so many clues to read it the right way!

But the small change does help, now even I'd struggle to miss the obvious (I hope).

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.