give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: When running the following query using Presto (either the CLI, or behind CADC TAP service) it takes a LONG time (table scan) when it should be fast.    -- Single object retrieval  SELECT source_id, designation, ra, decl, w1mpro, w1sigmpro  FROM wise_00.allwise_p3as_psd  WHERE source_id = '2813m031_ac51-041856'    As an example of a very similar query that runs fast:    -- Light curve retrieval  SELECT mjd, w1mpro_ep, w1sigmpro_ep, w2mpro_ep, w2sigmpro_ep, saa_sep, moon_masked  FROM wise_00.allwise_p3as_mep  WHERE source_id_mf = '2813m031_ac51-041856'    When I run the slow query (single object retrieval) I see that qserv gets a query to just return the entire table.  Then presto thinks it will do the filtering on source_id itself.  That is, it doesn't push down the WHERE predicate.  But WHY!    After some investigation, I see some differences in how the Presto query planner is doing things:    presto> explain SELECT source_id, designation, ra, decl, w1mpro, w1sigmpro FROM qserv.wise_00.allwise_p3as_psd WHERE source_id = '2813m031_ac51-041856';   Query Plan   -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------   - Output[source_id, designation, ra, decl, w1mpro, w1sigmpro] => [source_id:char(28), designation:char(20), ra:decimal(10,7), decl:decimal(9,7), w1mpro:decimal(5,3), w1sigm   - RemoteExchange[GATHER] => designation:char(20), ra:decimal(10,7), decl:decimal(9,7), source_id:char(28), w1mpro:decimal(5,3), w1sigmpro:decimal(4,3)    - ScanFilter[table = qserv:qserv:wise_00.allwise_p3as_psd:wise_00:null:allwise_p3as_psd, filterPredicate = ("source_id" = CAST('2813m031_ac51-041856' AS char(28)))]   decl := JdbcColumnHandle\{connectorId=qserv, columnName=decl, jdbcTypeHandle=JdbcTypeHandle\{jdbcType=3, columnSize=9, decimalDigits=7}, columnType=decimal(9,   w1sigmpro := JdbcColumnHandle\{connectorId=qserv, columnName=w1sigmpro, jdbcTypeHandle=JdbcTypeHandle\{jdbcType=3, columnSize=4, decimalDigits=3}, columnType=   source_id := JdbcColumnHandle\{connectorId=qserv, columnName=source_id, jdbcTypeHandle=JdbcTypeHandle\{jdbcType=1, columnSize=28, decimalDigits=0}, columnType   designation := JdbcColumnHandle\{connectorId=qserv, columnName=designation, jdbcTypeHandle=JdbcTypeHandle\{jdbcType=1, columnSize=20, decimalDigits=0}, column   w1mpro := JdbcColumnHandle\{connectorId=qserv, columnName=w1mpro, jdbcTypeHandle=JdbcTypeHandle\{jdbcType=3, columnSize=5, decimalDigits=3}, columnType=decima   ra := JdbcColumnHandle\{connectorId=qserv, columnName=ra, jdbcTypeHandle=JdbcTypeHandle\{jdbcType=3, columnSize=10, decimalDigits=7}, columnType=decimal(10,7)     (1 row)    The important part is:    filterPredicate = ("source_id" = CAST('2813m031_ac51-041856' AS char(28)))]         I'm wondering if Presto thinks because it's having to do a typecast, that it can't push this down as a simple predicate.    But then I asked myself why is this different than the fast query (light curve retrieval).  The difference seems to be that in the slow query, source_id's column type is char(28), and for the light curve, the source_id_mf column is a varchar.    After talking with the team, we're not really sure why the column type is different.  The source_id I'm using isn't even a full 28 characters.  I've tried to pad it out myself with extra spaces, but Presto still tries to cast it anyway.  And I'm not sure why that difference is causing such a problem for presto.    Possible ways forward:    First, I have to ask the presto team what is up, and try to debug this.    Second, if it's something that's unworkable, it might make sense to just use varchar column types instead, especially since these columns aren't actually fixed length strings.
Answer: 48969.0