Postgres оптимизация вопроса?

PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit

/*------ 04.02.2015 8:40:12 --------*/

EXPLAIN ANALYZE   SELECT  EXTRACT(EPOCH FROM   "F_Date"),
				"F_ConvertedValue",
				"F_TagName_ID" FROM
				"SC_Tag"."T_TagData"
				where
                "F_Date" > (localtimestamp - interval'1 hour') and
				"F_TagName_ID" in (73,72,39,64,76,75) 
				
				ORDER BY "F_Date" asc;;

/* Результат : "LOG:  duration: 11276.442 ms  statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) ORDER BY "F_Date" asc;;

возвращено записей: 7 (выполнено: 11,279 с; всего: 11,279 с)" */



/*------ 04.02.2015 8:49:52 --------*/

EXPLAIN ANALYZE   SELECT  EXTRACT(EPOCH FROM   "F_Date"),
				"F_ConvertedValue",
				"F_TagName_ID" FROM
				"SC_Tag"."T_TagData"
				where
                "F_Date" > (localtimestamp - interval'1 hour') and
				"F_TagName_ID" in (73,72,39,64,76,75) 
				
				--ORDER BY "F_Date" asc;;

/* Результат : "LOG:  duration: 9359.324 ms  statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75)

возвращено записей: 4 (выполнено: 9,360 с; всего: 9,375 с)" */

это вообще кошмарно. может имеет смысл сортировать уже на клиенте али может какие другие соображения будут?

DoomUnit

PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit /*------ 04.02.2015 8:40:12 --------*/ EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) ORDER BY "F_Date" asc;; /* Результат : "LOG: duration: 11276.442 ms statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) ORDER BY "F_Date" asc;; возвращено записей: 7 (выполнено: 11,279 с; всего: 11,279 с)" */ /*------ 04.02.2015 8:49:52 --------*/ EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) --ORDER BY "F_Date" asc;; /* Результат : "LOG: duration: 9359.324 ms statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) возвращено записей: 4 (выполнено: 9,360 с; всего: 9,375 с)" */ это вообще кошмарно. может имеет смысл сортировать уже на клиенте али может какие другие соображения будут?

кошмарно быт таким negsv vskfrjv, и не видеть 29лямов rows removed by filter в приведенном собою же плане.

я так скажу -- "уж лучше на клиенте фильтровать " убив перед этим клиента 30 лямами записей, положив его наконец лицом вниз, и всыпав розог.


кстати, какого хера вы текст картинкой вставляете ? чтобы вас труднее было внего носом ткнуть ? так я и так скажу что вы pfghtltkmysq gblfhfc

убивать убивать убивать dfnys[ gblfhfcjd

DoomUnit, оба запроса на горячую запускались? Т.е. данные уже подгрузились в буферы? Как-то подозрительно выглядит двухсекундная сортировка менее, чем 10 строк (две секунды смотрю просто по разнице 11 против 9).

ну сервачок изрядно грузится просто. вот и ищу способы оптимизации. а как прибить 30 млн строк то?

rovan, т.е вас только сортировка смутила? ;)

так а как переписать запрос чтобы он быстрее работал?

DoomUnit,

Никак. Этот запрос просто прекрасен.

/\/\/\/\/\/\,

ой млин дал жару с сарказмом((

DoomUnit
так а как переписать запрос чтобы он быстрее работал?

Use The Index, Luke!