Skip to content

slowness in select #1397

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
loic-guenin opened this issue Jan 10, 2020 · 10 comments
Open

slowness in select #1397

loic-guenin opened this issue Jan 10, 2020 · 10 comments

Comments

@loic-guenin
Copy link

loic-guenin commented Jan 10, 2020

Hello
I face huge slowness when using DynamicParameters with a list.

/**** The setup ****/
I am using Dapper 2.0.30 framework .Net 4.6.2.
My Db is Azure SQL Server As a service from Azure.

The table I request has this structure:

TABLE [MY_TABLE](
	[first_id] [numeric](12, 0) NOT NULL,
	[second_id] [int] NOT NULL,
	[entry_start] [datetime] NOT NULL,
	[entry_end] [datetime] NOT NULL,
	[value] [numeric](20, 10) NULL,
 CONSTRAINT [PK_MyTable] PRIMARY KEY CLUSTERED 
(
	[first_id] ASC,
	[second_id] ASC,
	[entry_start] ASC,
	[entry_end] ASC
)

/**** The prove that this is not an index problem ****/
When I do the following, there is no problem, it is almost instantaneous:

var request = "select first_id, second_id, entry_start, entry_end, value MY_TABLE where first_id in (2, 3) and entry_start >= @start_date and entry_end <= @end_date";

var param = new DynamicParameters();
param.Add("start_date", startDate);
param.Add("end_date", endDate);
var result = connection.Query<MyTableDto>(request, param);

/**** The problem ****/

But when I want to use a param for first_id, the request remains stucked!!

var request = "select first_id, second_id, entry_start, entry_end, value MY_TABLE where first_id in @ids and entry_start >=  @start_date and entry_end <= @end_date;";
var ids = new List<int> { 2, 3 };
var param = new DynamicParameters();
param.Add("ids", ids);
param.Add("start_date", startDate);
param.Add("end_date", endDate);
var result = connection.Query<MyTableDto>(request, param);

/**** Help please :) ****/
Do you have any idea of what causes this slowness?

Regards!

@mgravell
Copy link
Member

mgravell commented Jan 10, 2020

The first thing I'd try here would be "option unknown", i.e. try:

const string request = @"
select first_id, second_id, entry_start, entry_end, value
from MY_TABLE
where first_id in @ids
and entry_start >=  @start_date and entry_end <= @end_date
option (optimize for (@ids unknown));";

the formatting here is just for readability; the only functional difference is the addition of option (optimize for (@ids unknown)), which tells SQL Server not to make indexing/strategy assumptions about the query based on what the values are the first time the query is run.

Any use?

@mgravell
Copy link
Member

Additional and it shouldn't really matter, but you might find it more convenient to do:

var result = connection.Query<MyTableDto>(request, new {
    ids,
    start_date = startDate,
    end_date = endDate
});

This is a completely unrelated topic and shouldn't impact RDBMS performance - just: you might find it more convenient.

@loic-guenin
Copy link
Author

Thank you Marc. Unfortunately, still the same behaviour.... Time out when requesting with @ids as DynamicParams :(

@mgravell
Copy link
Member

If you code it as regular ADO.NET but with parameters: does it time out there? I'm trying to narrow down on where the problem is occurring

@loic-guenin
Copy link
Author

:(
My problem is about the array parameter

in @providerid

Is it possible to have such parameter with ADO.NET ?

@mgravell
Copy link
Member

mgravell commented Jan 13, 2020 via email

@loic-guenin
Copy link
Author

Ok so no timeout with ADO.NET...

@temnava
Copy link

temnava commented Jun 3, 2020

Is there any progress about this issue?

1 similar comment
@shiyi-lab
Copy link

Is there any progress about this issue?

@mgravell
Copy link
Member

Without specific reproducible scenarios we can work with, it isn't obvious that there even is a problem, let alone what should be done (at any layer, not necessarily Dapper) to resolve it. If folks want to help work with us on specific concrete examples, great! But ... we can't do much in a knowledge vacuum.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants