You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Pligin (Jira)" <ji...@apache.org> on 2024/06/14 11:49:00 UTC
[jira] [Updated] (IGNITE-22506) Table size can be useful in many ways including SQL planning. Also users expect to have such an API exposed to them.
[ https://issues.apache.org/jira/browse/IGNITE-22506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vladimir Pligin updated IGNITE-22506:
-------------------------------------
Description:
Currently there is no equivalent for cache.size().
The only way to get the size is
{code:java}
select count(*) from table {code}
And this is a is slow operation as it scans the entire dataset.
Initially we should start by providing an eventually-consistent size table.sizeEstimate() It needs to be the true size under no load, and it can kind of show whatever under load. It is NOT a transactional method. We might even forbid to call it in a transactional context.
For SQL, let's at least make sure that count can execute over the index without reading the actual data. This would be a useful optimization for many cases and should give a semi-reasonable performance for both RW and RO.
I think it's also possible to delegate select count from table to table.sizeEstimate() when it isn't in an explicit transaction.
was:
Currently there is no equivalent for `cache.size()`.
The only way to get the size is
{{}}
{code:java}
select count(*) from table {code}
{{{}{}}}And this is a is slow operation as it scans the entire dataset.
Initially we should start by providing an eventually-consistent size table.sizeEstimate() It needs to be the true size under no load, and it can kind of show whatever under load. It is NOT a transactional method. We might even forbid to call it in a transactional context.
For SQL, let's at least make sure that count(*) can execute over the index without reading the actual data. This would be a useful optimization for many cases and should give a semi-reasonable performance for both RW and RO.
I think it's also possible to delegate select count(*) from table to table.sizeEstimate() when it isn't in an explicit transaction.
> Table size can be useful in many ways including SQL planning. Also users expect to have such an API exposed to them.
> --------------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-22506
> URL: https://issues.apache.org/jira/browse/IGNITE-22506
> Project: Ignite
> Issue Type: Epic
> Reporter: Vladimir Pligin
> Priority: Major
>
> Currently there is no equivalent for cache.size().
> The only way to get the size is
> {code:java}
> select count(*) from table {code}
> And this is a is slow operation as it scans the entire dataset.
> Initially we should start by providing an eventually-consistent size table.sizeEstimate() It needs to be the true size under no load, and it can kind of show whatever under load. It is NOT a transactional method. We might even forbid to call it in a transactional context.
> For SQL, let's at least make sure that count can execute over the index without reading the actual data. This would be a useful optimization for many cases and should give a semi-reasonable performance for both RW and RO.
> I think it's also possible to delegate select count from table to table.sizeEstimate() when it isn't in an explicit transaction.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)