On Mon, Aug 12, 2019 at 5:03 PM Luís Roberto Weck
mailto:luisrobe...@siscobra.com.br>> wrote:
If you modify last_user_event_2 to select user and event info in
the view, and just put there where clause directly on the view
which is not joined to anything, instead of on the "extra cop
On Mon, Aug 12, 2019 at 5:03 PM Luís Roberto Weck <
luisrobe...@siscobra.com.br> wrote:
> If you modify last_user_event_2 to select user and event info in the view,
> and just put there where clause directly on the view which is not joined to
> anything, instead of on the "extra copy" of the users
> If you modify last_user_event_2 to select user and event info in the view,
> and just put there where clause directly on the view which is not joined to
> anything, instead of on the "extra copy" of the users table like you were
> showing previously, I would expect that the performance should
It seems like it should be-
SELECT * FROM users u JOIN last_user_event_1 e USING (user_id,user_group);
--OR--
SELECT * FROM last_user_event_2 e;
for them to produce the same result set, since the last_user_event_2
already (could) have users info in it very simply by select * instead of
e.* in that
> The obfuscation makes it difficult to guess at the query you are writing and
> the schema you are using. Can you provide any additional information without
> revealing sensitive info?
>
> 1) Do you have an index on ( user_id ASC, timestamp_inc DESC ) ?
> 2) Sub-queries can't be re-written inl
The obfuscation makes it difficult to guess at the query you are writing
and the schema you are using. Can you provide any additional information
without revealing sensitive info?
1) Do you have an index on ( user_id ASC, timestamp_inc DESC ) ?
2) Sub-queries can't be re-written inline by the opti
