Nearest Neighbor Query takes 7 minutes

Question

Hello there, First time poster on the forums. 
I've been looking into spatial comparison recently and have come across a few problems. The query I run takes 7 minutes to return the nearest neighbor. 
My table that has the Geographical locations is of the following structure and has 1.7 million rows. 
CREATE TABLE [dbo].[PostCodeData](
[OutwardCode] [varchar](4) NOT NULL,
[InwardCode] [varchar](3) NOT NULL,
[Longitude] [float] NULL,
[Latitude] [float] NULL,
[GeoLocation] [geography] NULL,
CONSTRAINT [PK_PostCodeData] PRIMARY KEY CLUSTERED
[OutwardCode] ASC,
[InwardCode] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
I have another table with many records on which I only have a Geography point (which I call Geolocation) and I'm trying to get the postcode from the PostCodeData table based on the nearest [GeoLocation] naturally.
This is my query at the moment :
SELECT top 2 [PostCode]
,[Geolocation]
, (select top 1 pc.InwardCode from PostCodeData pc order by pc.GeoLocation.STDistance(bg.Geolocation)) found_post_code
FROM [tbl_potatoes] bg
where bg.Geolocation is not null
This query is taking 7 minutes and as you can see I'm only doing this for 2 (top 2) records from the burning_glass table. What would happen if I wanted to process the whole table which has like 700k rows.
What I've tried: 
1. Created a spatial index.
2. Followed a post somewhere on these forums about applying it as a hint (WITH: WITH (INDEX(ixs_postcode)))
It didn't let me apply the hint and gave the following error : 
Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN.
Any help is appreciated. 

Answer 1

Just before the end of the day yesterday, a colleague of mine spotted the missing 'Where' in the subquery and we added it in.
The query now looks as such : 
UPDATE top(200) tbl_potatoes
SET PostCode =
select top 1 pc.OutwardCode
from PostCodeData pc
where pc.GeoLocation.STDistance(Geolocation) < 1000
order by pc.GeoLocation.STDistance(Geolocation)
WHERE Geolocation is not null;
The problem is, this query still takes a while. It now takes 3min27seconds for 200 rows. Not that this bit of math would be accurate in any way however if it takes 207seconds to do 200 rows, to do 300,00 it will most likely take somewhere between 80 to 90
hours. 
This is hardly going to be something that is going to work.
That was the update - the SELECT statement :
SELECT top 200 [PostCode]
,[Geolocation]
, (select top 1 pc.OutwardCode
from PostCodeData pc
where pc.GeoLocation.STDistance(bg.Geolocation) < 1000
order by pc.GeoLocation.STDistance(bg.Geolocation)) found_post_code
FROM [tbl_potatoes] pot
where Geolocation is not null
Takes just 23seconds for 200 records. Meaning it would take around 10 hours for 300k.
I tried Isaacs second example where he uses the STBuffer(10000) but it leads even more time in the select statement and quite frankly I don't get what is going on in his 3rd example where he talks about his declarative syntax.