[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OSSTEST PATCH 08/14] Executive: Use index for report__find_test

  • To: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • From: Ian Jackson <ian.jackson@xxxxxxxxxx>
  • Date: Wed, 22 Jul 2020 14:49:51 +0100
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 22 Jul 2020 13:50:20 +0000
  • Ironport-sdr: ipHFvHi5QGu2VadyFS6Fyf4ZelRNo3p2OSndFaUhQiEatTRftXeMQdhJiOflKEh76lRNMFxMhg MJOcnAPKn0n0Puf+fTY5eUqPCYPYGTaw8vFfV4Uc/gLDMbPhbmmwWySX4V9arhXcZzca9SHOWd jibS2bJB64MTRWZ3ohS0kQekQfP60xneokZRWqbqlB/lb9QuFQdQ/RjXTtV91y+F1+YypeQj/R zTC/m7edZFQ4Nt9R4PJR/FT1a5NBPpfmwKQPN9NLjXn8zJ97UlkAv3Rhb+cwPPzVVJkoG1gIeO k/c=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

George Dunlap writes ("Re: [OSSTEST PATCH 08/14] Executive: Use index for 
> > On Jul 21, 2020, at 7:41 PM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote:
> > Example query before (from the Perl DBI trace):
> So this says:
> Get me all the columns
> for the highest-numbered flight
> Where:
>   There is at least one runvar for that flight has the specified $name and 
> $value
>   And the job is *not* like build-%-prev or build-%-freebsd
>   The flight number (?) is <= 151903, and blessing = real
>   For the specified $branch


> What’s the “TRUE and flight <= 151903” for?

These queries are programmetically constructed.  In this case, the
flight condition is not always there.  My test case had a
--max-flight=151903 on the command line: this is a debugging option.
It avoids newly added stuff in the db confusing me and generally
disturbing things.  This is implemented with a condition variable
which contains either "" or "and flight <= 151903".  Doing it this way
simplifies the generation code.

> And this says (effectively)
> Get me <flight, started, blessing, branch, intended>
> From the highest-numbered flight
> Where
>   That flight has a runvar with specified name and value
>   The job *doesn’t* look like “build-%-prev” or “build-%-freebsd”
>   flight & blessing as appropriate
>   branch as specified.

I think so, yes.

> Isn’t the r.flight = f.flight redundant if we’re joining on flight?

Indeed it is.  I guess I can add a patch at theend to delete that.

> Also, in spite of the paragraph attempting to explain it, I’m afraid
> I don’t understand what the “AS sub WHERE TRUE” is for.

The reason for the subquery is not evident in the SQL.  It's because
of the Perl code which generates this query.  The same code is used to
generate queries that start with things like
   SELECT * ...
   SELECT COUNT(*) AS count ...
The perl code gets told "*" or "COUNT(*) AS count".  The call sites
that pass "*" expect to see fields from flights.  It would be
possible to change "*" to the explicit field list everywhere, but
it was much easier to do it this way.

(The WHERE TRUE is another one of these stubs where a condition might

> But it looks like the new query should do the same thing as the old
> query, assuming that the columns from the subquery are all the
> columns that you need in the correct order.

The subquery columns are precisely the columns currently existing in
he flights table.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.