Openquery performance with different number of columns

Question

I have a query that uses openquery and takes too long time. The query looks like this:

SELECT *
FROM OPENQUERY(LINKEDSERVER,
'SELECT column1, column2, column3, ..., column50
FROM someTable'
)

So it takes more than an hour. However, I noticed that if I select only one column it takes just one minute:

SELECT *
FROM OPENQUERY(LINKEDSERVER,
'SELECT column1
FROM someTable'
)

So obviously it depends on the number of columns that I select. The question is how to make faster the query with 50 columns?

UPDATE:

I still have the issue so I want to add a couple of details.

1. In my real query I do have the WHERE filter, but I didn't mention it in my question because I'm sure it doesn't matter.
2. The queries works much faster if I run them directly on the remote server.
3. It doesn't look as a channel issue since when I try to execute a multiple same queries in parallel they complete in the same time as a single query.
4. From my point of view it looks like there is an issue with driver or something like this.

Answer 1

It's not about the number of columns, but their cumulative size. You have at least one very large-sized column in your query, if the filter that you have is the same in both cases.

So, you will need to figure out which column is the big one, by looking at the way your table was defined in the first place. Try running the query with one column at a time and do this for all your columns. This will allow you to find out what column's writing is the slowest.

Now, if you have this kind of extremely large column values, you will need to figure out whether you need that column. If not, then you can simply remove it from the query and it should execute in a much quicker pace. If you need the column(s) that slow down the query, then you will either accept that the query takes a long while to execute, or separate the slow columns from the query. You may execute the query without the large columns and then execute the slow-part of your query separately, possibly via packet runs.

So, if you want some quick early results, then you can omit the large columns from the query and have a long-running job later that gets those values. So, your long texts and binary large objects will get later into the target, but username and email is there quickly.