Flexviews: Refresh Takes a Long Time. Normal?

[jamiejackson]

I'm still evaluating Flexviews (locally), to see if it's a good fit for our production application.

I have a (not-materialized) view that takes 11s. After turning that into an MV, a refresh (the first one) takes something like 20m, and I don't think it's really even completing.

I run:

set @mv_name = 'tap_mvw_workplangrantees_10';
set @mv_schema = 'myschema';
CALL flexviews.refresh(flexviews.get_id(@mv_schema, @mv_name), 'COMPUTE',  NULL);

...and no matter how many times I run that, it always goes on and on. First, the client times out at 10 minutes; then, i monitor the PROCESSLIST for another 10 minutes or so, until it stops churning.

I also tried purging the binary logs with purge binary logs before '2016-01-01';, but it doesn't seem to help.

Ideas?

[jamiejackson]

In case it matters, this was run after applying the patch from #127 to fix my problem in #126.

[jamiejackson]

I'm reading through a blog post that explains the *_delta table:

To bring the index up to date we must refresh it. Usually you will use the ‘BOTH’ mode to ‘COMPUTE’ and ‘APPLY’ the changes at the same time, but I am going to use COMPUTE mode to show you what ends up in the delta table...

For what it's worth, there's nothing in the delta table (SELECT count(*) FROM tap_mvw_workplangrantees_10_delta; returns 0), but maybe I wouldn't potentially see anything in there until a second successful refresh.

[jamiejackson]

Actually, I see there's a problem earlier in the process: flexviews.enable() isn't populating the MV in the first place. I should get that solved, first.

[greenlion]

Hi,

FlexCDC needs to be working to refresh a view. In particular, resetting the logs would require you to reset the config for flexcdc (or truncate binlog_consumer_status I suppose).