[MDEV-6547] select count(*) on hash partitions does a sorted index scan Created: 2014-08-07  Updated: 2023-12-12

Status: Open
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.12
Fix Version/s: 11.0

Type: Bug Priority: Minor
Reporter: Rich Prohaska Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ubuntu


Issue Links:
Relates
relates to MDEV-371 Unique indexes for blobs Closed

 Description   

select count(*) on hash partitions does a sorted index scan. the sort is unnecessary since the count operator is commutative. this problem also exists in MySQL 5.5 but is fixed in MySQL 5.6.19.



 Comments   
Comment by Elena Stepanova [ 2014-08-13 ]

Hi Rich,

Could you please provide an example – CREATE TABLE and the plan that you see (or any other indications that you use to detect the sorted index scan)?

Comment by Rich Prohaska [ 2014-08-13 ]

run mysqld with gdb and put a breakpoint at ha_partition::index_init
create table t (id bigint not null auto_increment primary key) partition by hash(id) partitions 2;
insert some rows into t.
select count(*) from t
the breakpoint hits and and the sorted parameter is true
ha_partition::index_init (this=0x7ffd81caa088, inx=0, sorted=true)
this causes the partition storage engine to sort the result set.
for tokudb 7.1.8-rc5, we think that this is a 2x slowdown.
in contrast, mysql 5.6 uses an unsorted indexing operation for this query.

Comment by Elena Stepanova [ 2014-08-13 ]

Thanks, yes, I'm getting it this way also.
Leaving to psergei to decide if it's a bug and where it can/should be fixed, 10.0 in 'Fix Version' is tentative and can be changed both ways if necessary.

Generated at Thu Feb 08 07:12:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.