explain analyze 를 쿼리 앞에 붙이셔서 쿼리 플랜을 보여주시면 답을 얻으시는데 도움이 됩니다.

댓글로 쿼리 플랜을 올려주세요

짐작 컨데, order by 에서 비용을 다 잡아먹나보네요.

일다은 환경설정으로 work memory 량을 늘려주면 첫번째 쿼리는 늦더라도 두번째 쿼리는 좀 빠를 수도 있습니다. ^^

share 메모리는 그만큼 크게 잡아줄 필요가 없습니다. 

동시 커넥션 되는 클라이언트 갯수만 감안해서 할당해 주면 됩니다.

제가 보기에는 다른 방법을 쓴다고 하더라도, 현재 쿼리로는 답이 나오지 않을 것 같습니다.
 tsearch 의 인덱스와 write_time 칼럼의 인덱스를 어떻게 하면 같이 쓸 수 있을까 ?

이 고민을 하셔야할 것 같습니다. 

write_time 이 insert 될때만 그 값이 지정되고 어떠한 경우에도 변경 되지 않을 것이며, 
그 해당 자료가 잦은 delete 를 하지 않는다면, write_time 칼럼 값으로 인덱스를 만들고,

tsearch 인덱스와 write_time 인덱스 두개를 같이 쓸 방법을 찾아야 원하는 결과를 얻을 수 있을 것 같습니다. 

우선 답글 감사드립니다. ^^

위와 같은 쿼리 실행시의 쿼리플랜은 아래와 같습니다.

"Limit  (cost=7222.50..7222.53 rows=10 width=8) (actual time=11233.460..11233.467 rows=10 loops=1)"
"  ->  Sort  (cost=7222.50..7227.50 rows=1998 width=8) (actual time=11233.458..11233.461 rows=10 loops=1)"
"        Sort Key: tblsearchdata7.write_time"
"        ->  Nested Loop  (cost=149.27..7112.97 rows=1998 width=8) (actual time=419.622..11207.968 rows=21351 loops=1)"
"              ->  Function Scan on q  (cost=0.00..0.01 rows=1 width=32) (actual time=0.005..0.006 rows=1 loops=1)"
"              ->  Bitmap Heap Scan on tblsearchdata7  (cost=149.27..7082.97 rows=1999 width=185) (actual time=419.610..11191.394 rows=21351 loops=1)"
"                    Recheck Cond: ((tblsearchdata7.title_vector @@ q.q) OR (tblsearchdata7.content_vector @@ q.q))"
"                    ->  BitmapOr  (cost=149.27..149.27 rows=1999 width=0) (actual time=393.200..393.200 rows=0 loops=1)"
"                          ->  Bitmap Index Scan on idxtitlevector7  (cost=0.00..44.09 rows=999 width=0) (actual time=145.901..145.901 rows=9957 loops=1)"
"                                Index Cond: (tblsearchdata7.title_vector @@ q.q)"
"                          ->  Bitmap Index Scan on idxcontentvector7  (cost=0.00..104.69 rows=999 width=0) (actual time=247.298..247.298 rows=14764 loops=1)"
"                                Index Cond: (tblsearchdata7.content_vector @@ q.q)"
"Total runtime: 11234.951 ms"

김상기님이 언급하신 것처럼 해당 테이블에 데이터가 입력된 후 수정은 전혀 일어나지 않습니다. 다만 새

로운 데이터가 계속 추가될 뿐입니다. 처음에는 날짜를 내림차순 인덱스로 잡고 클러스터링 해서 사용하

려고 했었는데 PG는 내림차순 인덱스를 지원하지 않더라구요. 그래서 사용하는 임시 방편이 일일 업데이

트가 있을 때 새로운 데이터를 입력하고 날짜 내림차순으로 테이블을 새로 생성합니다. 이렇게 정렬을 해

서 사용하는게 시간도 오래 걸리고 너무 번거로운 작업들이 많아 ORDER BY로 다시 해결해 보려고 했지

만 잘 되지가 않네요. ^^

실제로 가장 오래걸리는 부분은 21351 개의 row를 sort하는 부분이네요..

단순히 드릴수 있는 답변은 work_mem을 많이~ 늘려 보심이 ^^;;