ndate 자료형을 timestamp 값으로 바꾸고,

인덱스를 ndate와, char_name 칼럼 두개를 함께 걸고,

select ahourdate from tb_item where ndate > '2008-12-29 01:00:00'::timestamp without time zone and ndate < '2008-12-29 02:00:00'::timestamp without time zone and char_name = 'MGHOLIC03' order by ndate desc limit 30;

이런식이면 인덱스를 사용하면서 빠르게 처리하지 않을까싶습니다.

일단 bigint 자료형이고, 저렇게 자료가 많은 경우라면, 쿼리최적화기가 그 범위를 보고 인덱스를 쓸 것인가 말 것인가를 결정할 것 같네요 (제가 최적화기를 만든다면 그렇게 할듯) 만일 이 가정이 맞다면 범위가 너무 커져서 인덱스 사용을 하지 않을 가능성이 큽니다.

게다가 inline view 를 쓰게 되면 그 view의 쿼리 결과에 대한 인덱스 또한 사용이 불가능합니다. 인덱스를 쓸 수가 없으니.

------------------

count(*) 문제는 따로 고민해보셔야합니다. 저렇게 자료가 많은데, row count를 찾아내야할 상황이면 집계테이블이 하나 존재해야할 것 같네요.

------------------

이것보다 가장 크게 고민하셔야하는 부분,

자료가 많이 쌓일 때, 그 자료의 인덱스에 대한 크기 또한 고민의 대상이 되어야합니다.

저 상태에서 2억 ~ 3억으로 계속 관리를 하고 싶다면,

인덱스 분활도 생각해 보셔야합니다.

그렇지 않으면 로그 insert 작업에서 갑자기 속도가 떨어질 것이 예상됩니다.

------------------

멋지게 풀어보시고, 잘 풀렸으면 그 노하우를 이곳에 전수해 주시길.

제글은 아니지만 김상기님 답변 정말 깔끔하고 시원하네영

배우고 갑니다 감사합니다.

답변감사합니다. 
새로 timestamp 컬럼을 만들거나
집계테이블등 많이 고민을 해봐야겠네요 !