Claudio Valderrama C. wrote:

>
> I see people proposing fetches and several variations of time to stop the
> query. The problem with time is that despite an accurate clock, time will be
> subjective to users. The problem with fetches is that given a sort, all
> records have to be internally retrieved and sorted before the first fetch
> happens,

Ah, there you have confused fetches with retrievals. A fetch is an
internal request for a database page. The first fetch of most requests
is for some part of the metadata, as part of parsing the request. If
the whole of the metadata is already in the metadata cache (as opposed
to page cache, the "metadata cache" is a set of structures in memory
like relation blocks, index blocks etc.), the first fetch might be a
pointer page or an index root page. In the case of a sort, there would
be no fetches after the sort starts ... everything having been read before.

> then why not define reads? The problem with reads is that they're
> more abstract for the user. Pages read, records reads, do we count record
> versions needed to reconstruct the record, etc.

Reads, at least in the sense of performance monitoring, are requests for
page fetches that can not be resolved from the page cache. In answer to
your question, every page read - data, indexes, pointer pages,
generator pages, page inventory pages, header page, tip pages - every
time the physical I/O module asks the operating system to read from the
disk counts as a read.

Regards,


Ann