MySQL Forums :: Partitioning :: Count(*) query is slower on partitioned table


Advanced Search

Re: Count(*) query is slower on partitioned table
Posted by: Darren Demicoli ()
Date: December 10, 2016 06:48AM

Thanks for your reply.

In my real case the partitioning is on a datetime column - the actual idea is to use partitions to simplify deletions and reclamation of storage space. So, we are not after a performance improvement, but such a degradation is very worrying.

In the meantime, another thing I have noted is that as more columns are added (alter) to the partitioned table, then this COUNT query takes longer and longer. (this may be one of the reason why my actual query takes much longer). Once again, this does not make sense to me because this query should be "using index" - ie: should not need to access the main table, right? So my "suspicion" is that something is wrong in the Mysql/mariadb part that handles partitioning such that InnoDb still has to reference the main table. I will try to test with most recent version of Mysql 5.7 to ensure it is not related to index condition pushdown (even though I do not have a filtering condition here) and get back to you.

--
Darren Demicoli
Devops Engineer
http://www.xcaliber.com

Options: ReplyQuote


Subject Views Written By Posted
Count(*) query is slower on partitioned table 535 Darren Demicoli 12/03/2016 11:53AM
Re: Count(*) query is slower on partitioned table 183 Rick James 12/10/2016 12:30AM
Re: Count(*) query is slower on partitioned table 230 Darren Demicoli 12/10/2016 06:48AM
Re: Count(*) query is slower on partitioned table 186 Rick James 12/12/2016 01:56PM
Re: Count(*) query is slower on partitioned table 212 Darren Demicoli 12/13/2016 02:50PM
Re: Count(*) query is slower on partitioned table 156 Rick James 12/21/2016 12:35AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.