anonymous@RULINUX.NET~# Last login: 2024-05-04 02:08:39
Регистрация Вход Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск
[#] [Добавить метку] [Редактировать]
Скрыть

Ну так чо там с апгрейдом постгреса?

Чо на чо меняли, почему, помогло ли?

anonymous(*) (2011-10-05 12:39:12)

[Ответить на это сообщение]
[#] [Добавить метку] [Редактировать] Ответ на: Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 12:39:12
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Немного полегчало вроде. Но иногда все равно замерзает с 504.

anonymous(*)(2011-10-05 12:41:16)

Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
[#] [Добавить метку] [Редактировать] Ответ на: Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 12:39:12
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>Чо на чо меняли
Пытались обновить до 9.1 Но почему-то не заработало. Вобщем сейчас обновили с 8.3 до 8.4. Ближе к ночи по Иркутскому времени vitroot пообещал разобраться и с 9.1.

>почему
Очевидно же что из-за тормозов 8.3 на гораздо более мощном сервере по сравнению с моей 9.1 на локалхосте. Это <!-- Запрос SELECT count(*) AS cnt FROM comments where tid = '34536' выполнен за 1.685757 сек.--> явно не нормально. Для сравнения на локалке <!-- Запрос SELECT count(*) AS cnt FROM comments where tid = '34536' выполнен за 0.008151 сек.-->

>помогло ли
Немного. время сократилось в 2 раза по сравнению со вчерашним вечером.<!--Страница сгенерировалась за 2.380502 сек.--> Но это все-равно медленно.

Tux-oid(*)(2011-10-05 12:51:06)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 12:51:06
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Ах-да результат по тому-же запросу после обновления <!-- Запрос SELECT count(*) AS cnt FROM comments where tid = '34536' выполнен за 0.052306 сек.-->

Tux-oid(*)(2011-10-05 12:54:13)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 12:51:06
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

> на гораздо более мощном сервере по сравнению с моей
Ты когда сравниваешь, сразу план запроса вставляй с обеих машин. И показания из топа - во что он упирается - в ЦПУ или в диск.

Да, и я не верю что разница в производительности в 200 раз связана с версией СУБД :) Этого просто не может быть.

anonymous(*)(2011-10-05 12:59:41)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 12:54:13
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Какие-нибудь настройки в конфиге поменялись может?

anonymous(*)(2011-10-05 13:01:30)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 12:59:41
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>И показания из топа - во что он упирается - в ЦПУ или в диск.
все время в цпу упирается. Дисковая активность на нуле. Отжирает 60%-80% ЦПУ.

>Да, и я не верю что разница в производительности в 200 раз связана с версией СУБД :) Этого просто не может быть.
Может с настройками как связно. Может в зюзе постгресс патченный. Но я тебе показал именно те результаты которые мне выдало на веб страничку. Ах-да на серваке 2 ксеона и гиг оперативы. На локалке - целерон и 512 оперативы.

Tux-oid(*)(2011-10-05 13:07:16)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 13:01:30
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>Какие-нибудь настройки в конфиге поменялись может?
Вполне может быть.

Tux-oid(*)(2011-10-05 13:08:04)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 13:07:16
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

А может ты выложишь дамп БД, естественно без паролей, емейлов и im-ов? Тогда можно будет попробовать потестировать на реальных данных на разных машинах.

SystemV(*)(2011-10-05 13:15:04)

Emacs-w3m/1.4.414 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 13:07:16
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Слушай, а он всё время так напряжённо процессор жрал или только во время выполнения запроса? Если первое - то возможно и бага: я смотрю народ на потребление CPU жалуется в основном в связи с автовакуумом, но он вроде сам по себе должен цпу жрать, и на ненагруженной машине.

anonymous(*)(2011-10-05 13:25:59)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-05 13:15:04
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

> А может ты выложишь дамп БД, естественно без паролей, емейлов и im-ов? Тогда можно будет попробовать потестировать на реальных данных на разных машинах.
В новой БД они вроде и храниться-то кстати не должны, что облегчает дело.

anonymous(*)(2011-10-05 13:27:11)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 13:25:59
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Нет во время выполнения запроса.

Tux-oid(*)(2011-10-05 13:38:25)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 13:27:11
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>В новой БД они вроде и храниться-то кстати не должны, что облегчает дело.
Как это пароли не хранятся? IPшники не харнятся, а пароли хранятся ввиде md5-хешей.

Tux-oid(*)(2011-10-05 13:40:28)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 13:40:28
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Ну пароли сбросить - дело одного апдейта, я про остальное: насколько я понимаю у тебя раньше тебе базу расшарить мешали трудности с зачисткой айпишников и другой приватной информации и типа того?

anonymous(*)(2011-10-05 13:43:20)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 13:43:20
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

уже сменил на qwerty и [email protected], [email protected]. Ссылку дам как только загрузится на zalil.ru

Tux-oid(*)(2011-10-05 13:47:35)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-05 13:15:04
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

ловите ссылку на дамп http://zalil.ru/31812593

Tux-oid(*)(2011-10-05 13:49:52)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 13:49:52
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

wget-нул его с домашней машины, получил какой-то мусор, похожий на ХТМЛ со вставками джаваскрипта. w3m вообще нифига не показывает по данному урлу. Чо тебе на собственном хостинге файл не выложить?

anonymous(*)(2011-10-05 14:05:22)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 14:05:22
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

лови http://rulinux.net/dump.sql.gz

Tux-oid(*)(2011-10-05 14:21:53)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 14:21:53
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Much better :)

anonymous(*)(2011-10-05 14:23:50)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 14:23:50
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Ну чо, втянул базу..

SELECT count(*) AS cnt FROM comments where tid = 34536 кушает ~50 миллисеков

SELECT ALL * FROM comments WHERE timest > '2011-10-04 12:37:53' ORDER BY timest DESC OFFSET 0 LIMIT NULL => 60 миллисеков

SELECT t.id, t.cid, t.attached, t.prooflink, t.approved, t.approved_by, t.approve_timest, t.subsection, c.subject, c.comment, c.uid, c.timest FROM threads t INNER JOIN comments c ON t.cid = c.id WHERE t.approved=true AND t.section=1 ORDER BY t.attached <>true ASC, t.id DESC LIMIT 10 OFFSET 0 => 15 миллисеков

Тюксоид, Выкладывай наверное и postgresql.conf - чтобы можно было свой конфиг портить и смотреть где затормозит. У тебя есть какие-нибудь образцово-тормозные запросы сейчас?

anonymous(*)(2011-10-05 15:41:33)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 15:41:33
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Да они все по мелочи притормаживают. Вот в сумме и набегает. Вот например <!-- Запрос SELECT id FROM comments WHERE tid = '34824' ORDER BY id ASC выполнен за 0.230221 сек.--> А конфиг будет уже ближе к вечеру.

Tux-oid(*)(2011-10-05 16:14:41)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 16:14:41
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

text
# -----------------------------
# PostgreSQL configuration file
# -----------------------------
#
# This file consists of lines of the form:
#
#   name = value
#
# (The "=" is optional.)  Whitespace may be used.  Comments are introduced with
# "#" anywhere on a line.  The complete list of parameter names and allowed
# values can be found in the PostgreSQL documentation.
#
# The commented-out settings shown in this file represent the default values.
# Re-commenting a setting is NOT sufficient to revert it to the default value;
# you need to reload the server.
#
# This file is read on server startup and when the server receives a SIGHUP
# signal.  If you edit the file on a running system, you have to SIGHUP the
# server for the changes to take effect, or use "pg_ctl reload".  Some
# parameters, which are marked below, require a server shutdown and restart to
# take effect.
#
# Any parameter can also be given as a command-line option to the server, e.g.,
# "postgres -c log_connections=on".  Some paramters can be changed at run time
# with the "SET" SQL command.
#
# Memory units:  kB = kilobytes MB = megabytes GB = gigabytes
# Time units:    ms = milliseconds s = seconds min = minutes h = hours d = days


#------------------------------------------------------------------------------
# FILE LOCATIONS
#------------------------------------------------------------------------------

# The default values of these variables are driven from the -D command-line
# option or PGDATA environment variable, represented here as ConfigDir.

data_directory = '/var/lib/postgresql/8.3/main'         # use data in another directory
                                        # (change requires restart)
hba_file = '/etc/postgresql/8.3/main/pg_hba.conf'       # host-based authentication file
                                        # (change requires restart)
ident_file = '/etc/postgresql/8.3/main/pg_ident.conf'   # ident configuration file
                                        # (change requires restart)

# If external_pid_file is not explicitly set, no extra PID file is written.
external_pid_file = '/var/run/postgresql/8.3-main.pid'          # write an extra PID file
                                        # (change requires restart)


#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

# - Connection Settings -

#listen_addresses = 'localhost'         # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost', '*' = all
                                        # (change requires restart)
port = 5432                             # (change requires restart)
max_connections = 120                   # (change requires restart)
# Note:  Increasing max_connections costs ~400 bytes of shared memory per
# connection slot, plus lock space (see max_locks_per_transaction).  You might
# also need to raise shared_buffers to support more connections.
#superuser_reserved_connections = 3     # (change requires restart)
unix_socket_directory = '/var/run/postgresql'           # (change requires restart)
#unix_socket_group = ''                 # (change requires restart)
#unix_socket_permissions = 0777         # begin with 0 to use octal notation
                                        # (change requires restart)
#bonjour_name = ''                      # defaults to the computer name
                                        # (change requires restart)

# - Security and Authentication -

#authentication_timeout = 1min          # 1s-600s
ssl = true                              # (change requires restart)
#ssl_ciphers = 'ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH'      # allowed SSL ciphers
                                        # (change requires restart)
#ssl_renegotiation_limit = 512MB        # amount of data between renegotiations
#password_encryption = on
#db_user_namespace = off

# Kerberos and GSSAPI
#krb_server_keyfile = ''                # (change requires restart)
#krb_srvname = 'postgres'               # (change requires restart, Kerberos only)
#krb_server_hostname = ''               # empty string matches any keytab entry
                                        # (change requires restart, Kerberos only)
#krb_caseins_users = off                # (change requires restart)
#krb_realm = ''                         # (change requires restart)

# - TCP Keepalives -
# see "man 7 tcp" for details

#tcp_keepalives_idle = 0                # TCP_KEEPIDLE, in seconds;
                                        # 0 selects the system default
#tcp_keepalives_interval = 0            # TCP_KEEPINTVL, in seconds;
                                        # 0 selects the system default
#tcp_keepalives_count = 0               # TCP_KEEPCNT;
                                        # 0 selects the system default


#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------

# - Memory -

shared_buffers = 24MB                   # min 128kB or max_connections*16kB
                                        # (change requires restart)
temp_buffers = 8MB                      # min 800kB
#max_prepared_transactions = 5          # can be 0 or more
                                        # (change requires restart)
# Note:  Increasing max_prepared_transactions costs ~600 bytes of shared memory
# per transaction slot, plus lock space (see max_locks_per_transaction).
work_mem = 256MB                                # min 64kB
maintenance_work_mem = 8MB              # min 1MB
max_stack_depth = 2MB                   # min 100kB

# - Free Space Map -

max_fsm_pages = 153600                  # min max_fsm_relations*16, 6 bytes each
                                        # (change requires restart)
#max_fsm_relations = 1000               # min 100, ~70 bytes each
                                        # (change requires restart)

# - Kernel Resource Usage -

#max_files_per_process = 1000           # min 25
                                        # (change requires restart)
#shared_preload_libraries = ''          # (change requires restart)

# - Cost-Based Vacuum Delay -

#vacuum_cost_delay = 0                  # 0-1000 milliseconds
#vacuum_cost_page_hit = 1               # 0-10000 credits
#vacuum_cost_page_miss = 10             # 0-10000 credits
#vacuum_cost_page_dirty = 20            # 0-10000 credits
#vacuum_cost_limit = 200                # 1-10000 credits

# - Background Writer -

#bgwriter_delay = 200ms                 # 10-10000ms between rounds
#bgwriter_lru_maxpages = 100            # 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0          # 0-10.0 multipler on buffers scanned/round


#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------

# - Settings -

#fsync = on                             # turns forced synchronization on or off
#synchronous_commit = on                # immediate fsync at commit
#wal_sync_method = fsync                # the default is the first option
                                        # supported by the operating system:
                                        #   open_datasync
                                        #   fdatasync
                                        #   fsync
                                        #   fsync_writethrough
                                        #   open_sync
#full_page_writes = on                  # recover from partial page writes
#wal_buffers = 64kB                     # min 32kB
                                        # (change requires restart)
#wal_writer_delay = 200ms               # 1-10000 milliseconds

#commit_delay = 0                       # range 0-100000, in microseconds
#commit_siblings = 5                    # range 1-1000

# - Checkpoints -

#checkpoint_segments = 3                # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 5min              # range 30s-1h
#checkpoint_completion_target = 0.5     # checkpoint target duration, 0.0 - 1.0
#checkpoint_warning = 30s               # 0 is off

# - Archiving -

#archive_mode = off             # allows archiving to be done
                                # (change requires restart)
#archive_command = ''           # command to use to archive a logfile segment
#archive_timeout = 0            # force a logfile segment switch after this
                                # time; 0 is off


#------------------------------------------------------------------------------
# QUERY TUNING
#------------------------------------------------------------------------------

# - Planner Method Configuration -

enable_bitmapscan = on
enable_hashagg = on
enable_hashjoin = on
enable_indexscan = on
enable_mergejoin = on
enable_nestloop = on
enable_seqscan = on
enable_sort = on
enable_tidscan = on

# - Planner Cost Constants -

#seq_page_cost = 1.0                    # measured on an arbitrary scale
#random_page_cost = 4.0                 # same scale as above
cpu_tuple_cost = 0.01                   # same scale as above
cpu_index_tuple_cost = 0.005            # same scale as above
cpu_operator_cost = 0.0025              # same scale as above
effective_cache_size = 128MB

# - Genetic Query Optimizer -

#geqo = on
#geqo_threshold = 12
#geqo_effort = 5                        # range 1-10
#geqo_pool_size = 0                     # selects default based on effort
#geqo_generations = 0                   # selects default based on effort
#geqo_selection_bias = 2.0              # range 1.5-2.0

# - Other Planner Options -

#default_statistics_target = 10         # range 1-1000
#constraint_exclusion = off
#from_collapse_limit = 8
#join_collapse_limit = 8                # 1 disables collapsing of explicit
                                        # JOIN clauses


#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------

# - Where to Log -

#log_destination = 'stderr'             # Valid values are combinations of
                                        # stderr, csvlog, syslog and eventlog,
                                        # depending on platform.  csvlog
                                        # requires logging_collector to be on.

# This is used when logging to stderr:
#logging_collector = off                # Enable capturing of stderr and csvlog
                                        # into log files. Required to be on for
                                        # csvlogs.
                                        # (change requires restart)

# These are only used if logging_collector is on:
#log_directory = 'pg_log'               # directory where log files are written,
                                        # can be absolute or relative to PGDATA
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'        # log file name pattern,
                                        # can include strftime() escapes
#log_truncate_on_rotation = off         # If on, an existing log file of the
                                        # same name as the new log file will be
                                        # truncated rather than appended to.
                                        # But such truncation only occurs on
                                        # time-driven rotation, not on restarts
                                        # or size-driven rotation.  Default is
                                        # off, meaning append to existing files
                                        # in all cases.
#log_rotation_age = 1d                  # Automatic rotation of logfiles will
                                        # happen after that time.  0 to disable.
#log_rotation_size = 10MB               # Automatic rotation of logfiles will
                                        # happen after that much log output.
                                        # 0 to disable.

# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'


# - When to Log -

#client_min_messages = notice           # values in order of decreasing detail:
                                        #   debug5
                                        #   debug4
                                        #   debug3
                                        #   debug2
                                        #   debug1
                                        #   log
                                        #   notice
                                        #   warning
                                        #   error

#log_min_messages = notice              # values in order of decreasing detail:
                                        #   debug5
                                        #   debug4
                                        #   debug3
                                        #   debug2
                                        #   debug1
                                        #   info
                                        #   notice
                                        #   warning
                                        #   error
                                        #   log
                                        #   fatal
                                        #   panic

#log_error_verbosity = default          # terse, default, or verbose messages

#log_min_error_statement = error        # values in order of decreasing detail:
                                        #   debug5
                                        #   debug4
                                        #   debug3
                                        #   debug2
                                        #   debug1
                                        #   info
                                        #   notice
                                        #   warning
                                        #   error
                                        #   log
                                        #   fatal
                                        #   panic (effectively off)

#log_min_duration_statement = -1        # -1 is disabled, 0 logs all statements
                                        # and their durations, > 0 logs only
                                        # statements running at least this time.

#silent_mode = off                      # DO NOT USE without syslog or
                                        # logging_collector
                                        # (change requires restart)

# - What to Log -

#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = off
#log_checkpoints = off
#log_connections = off
#log_disconnections = off
#log_duration = off
#log_hostname = off
log_line_prefix = '%t '                 # special values:
                                        #   %u = user name
                                        #   %d = database name
                                        #   %r = remote host and port
                                        #   %h = remote host
                                        #   %p = process ID
                                        #   %t = timestamp without milliseconds
                                        #   %m = timestamp with milliseconds
                                        #   %i = command tag
                                        #   %c = session ID
                                        #   %l = session line number
                                        #   %s = session start timestamp
                                        #   %v = virtual transaction ID
                                        #   %x = transaction ID (0 if none)
                                        #   %q = stop here in non-session
                                        #        processes
                                        #   %% = '%'
                                        # e.g. '<%u%%%d> '
#log_lock_waits = off                   # log lock waits >= deadlock_timeout
#log_statement = 'none'                 # none, ddl, mod, all
#log_temp_files = -1                    # log temporary files equal or larger
                                        # than specified size;
                                        # -1 disables, 0 logs all temp files
#log_timezone = unknown                 # actually, defaults to TZ environment
                                        # setting


#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------

# - Query/Index Statistics Collector -

#track_activities = on
#track_counts = on
#update_process_title = on


# - Statistics Monitoring -

#log_parser_stats = off
#log_planner_stats = off
#log_executor_stats = off
#log_statement_stats = off


#------------------------------------------------------------------------------
# AUTOVACUUM PARAMETERS
#------------------------------------------------------------------------------

#autovacuum = on                        # Enable autovacuum subprocess?  'on'
                                        # requires track_counts to also be on.
#log_autovacuum_min_duration = -1       # -1 disables, 0 logs all actions and
                                        # their durations, > 0 logs only
                                        # actions running at least that time.
#autovacuum_max_workers = 3             # max number of autovacuum subprocesses
#autovacuum_naptime = 1min              # time between autovacuum runs
#autovacuum_vacuum_threshold = 50       # min number of row updates before
                                        # vacuum
#autovacuum_analyze_threshold = 50      # min number of row updates before
                                        # analyze
#autovacuum_vacuum_scale_factor = 0.2   # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1  # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000  # maximum XID age before forced vacuum
                                        # (change requires restart)
#autovacuum_vacuum_cost_delay = 20      # default vacuum cost delay for
                                        # autovacuum, -1 means use
                                        # vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1      # default vacuum cost limit for
                                        # autovacuum, -1 means use
                                        # vacuum_cost_limit


#------------------------------------------------------------------------------
# CLIENT CONNECTION DEFAULTS
#------------------------------------------------------------------------------

# - Statement Behavior -

#search_path = '"$user",public'         # schema names
#default_tablespace = ''                # a tablespace name, '' uses the default
#temp_tablespaces = ''                  # a list of tablespace names, '' uses
                                        # only default tablespace
#check_function_bodies = on
#default_transaction_isolation = 'read committed'
#default_transaction_read_only = off
#session_replication_role = 'origin'
#statement_timeout = 0                  # 0 is disabled
#vacuum_freeze_min_age = 100000000
#xmlbinary = 'base64'
#xmloption = 'content'

# - Locale and Formatting -

datestyle = 'iso, mdy'
#timezone = unknown                     # actually, defaults to TZ environment
                                        # setting
#timezone_abbreviations = 'Default'     # Select the set of available time zone
                                        # abbreviations.  Currently, there are
                                        #   Default
                                        #   Australia
                                        #   India
                                        # You can create your own file in
                                        # share/timezonesets/.
#extra_float_digits = 0                 # min -15, max 2
#client_encoding = sql_ascii            # actually, defaults to database
                                        # encoding

# These settings are initialized by initdb, but they can be changed.
lc_messages = 'C'                       # locale for system error message
                                        # strings
lc_monetary = 'C'                       # locale for monetary formatting
lc_numeric = 'C'                        # locale for number formatting
lc_time = 'C'                           # locale for time formatting

# default configuration for text search
default_text_search_config = 'pg_catalog.english'

# - Other Defaults -

#explain_pretty_print = on
#dynamic_library_path = '$libdir'
#local_preload_libraries = ''


#------------------------------------------------------------------------------
# LOCK MANAGEMENT
#------------------------------------------------------------------------------

#deadlock_timeout = 1s
#max_locks_per_transaction = 64         # min 10
                                        # (change requires restart)
# Note:  Each lock table slot uses ~270 bytes of shared memory, and there are
# max_locks_per_transaction * (max_connections + max_prepared_transactions)
# lock table slots.


#------------------------------------------------------------------------------
# VERSION/PLATFORM COMPATIBILITY
#------------------------------------------------------------------------------

# - Previous PostgreSQL Versions -

#add_missing_from = off
#array_nulls = on
#backslash_quote = safe_encoding        # on, off, or safe_encoding
#default_with_oids = off
#escape_string_warning = on
#regex_flavor = advanced                # advanced, extended, or basic
#sql_inheritance = on
#standard_conforming_strings = off
#synchronize_seqscans = on

# - Other Platforms and Clients -

#transform_null_equals = off


#------------------------------------------------------------------------------
# CUSTOMIZED OPTIONS
#------------------------------------------------------------------------------

#custom_variable_classes = ''           # list of custom variable class names

 

Tux-oid(*)(2011-10-05 16:21:08)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 16:14:41
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

У меня он 50 мсек дает.. Чему там набигать, если у тебя запросов штук десять на страницу, не больше.

Ты там вроде на каждый запрос ещё делаешь "UPDATE users SET last_visit" - он не тормозит на анонимусах?

anonymous(*)(2011-10-05 16:21:46)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 15:41:33
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>Ну чо, втянул базу..
Почти такие же цифры, постгрес 9.1.1. Главная генерится за ~1 сек, список форумов - за 1,5 сек.

Попозже доберусь до постгреса 8.3 и 8.4.

SystemV(*)(2011-10-05 16:27:10)

Emacs-w3m/1.4.414 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 16:21:46
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>Ты там вроде на каждый запрос ещё делаешь "UPDATE users SET last_visit" - он не тормозит на анонимусах?
Не делаю. last_visit обновляется при загрузке страницы. <!-- Запрос UPDATE users SET last_visit='2011-10-05 12:28:22' WHERE id='7' выполнен за 0.061698 сек.--> А тормозят именно запросы к таблице comments

Tux-oid(*)(2011-10-05 16:30:55)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 12:59:41
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

> Да, и я не верю что разница в производительности в 200 раз связана с версией СУБД :) Этого просто не может быть.
может. Блокировки и оптимизатор. Собственно за это ынтырпрайзу бабло и плотят, за умение написать оптимизированный запрос. Не тестируйте скорость на одном запросе, это бессмысленно. Надо сделать хотя бы десяток одновременно и смотреть тогда. Алсо иннер джоины и вложеные запросы суксь.

bugmaker(*)(2011-10-05 16:35:50)

Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.17) Gecko/20110422 Ubuntu/10.04 (lucid) Firefox/3.6.17
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-05 16:27:10
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Ну и у меня на локалке главная за секунду генерится.

Tux-oid(*)(2011-10-05 16:43:52)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-05 16:27:10
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Ох ты ж. Список сообщений в толксах:

Страница сгенерировалась за 8.81644 сек

SystemV(*)(2011-10-05 16:45:46)
Отредактировано SystemV по причине "не указана"
Emacs-w3m/1.4.414 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-05 16:45:46
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Кстати там я наткнулся на такой ужаснейший запрос с 2 иннер джойнами и вложенными подзапросами аж 4 уровня выполняющийся больше секунды.

sql
SELECT t.id, t.attached, c.subject, c.changing_timest, c.timest FROM threads t INNER JOIN (SELECT tm.tid, tm.subject, tm.timest, max(ch.changing_timest) AS changing_timest FROM comments ch INNER JOIN (SELECT tid, timest, subject FROM comments WHERE timest IN (SELECT min(timest) FROM comments WHERE tid IN (SELECT id FROM threads WHERE section='4' AND subsection='10')  GROUP BY tid)) tm ON ch.tid = tm.tid WHERE ch.tid IN (SELECT id FROM threads WHERE section='4' AND subsection='10')  GROUP BY ch.tid, tm.timest, tm.subject, tm.tid) c ON t.id = c.tid WHERE t.section ='4' AND t.subsection = '10' ORDER BY t.attached <>true ASC, c.timest DESC LIMIT 30 OFFSET 0
 

Tux-oid(*)(2011-10-05 17:07:33)
Отредактировано Tux-oid по причине "не указана"
Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-05 16:27:10
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

У меня 9.0.4, а сайт сегодня скачать и поставить наверное не смогу.

anonymous(*)(2011-10-05 17:10:01)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 17:07:33
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Этот похож на то, что рассматривали вчера.

anonymous(*)(2011-10-05 17:13:01)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 17:13:01
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

угу. Абсолютно такой-же. Я его уже заменил. Но сам запрос меня сейчас позабавил. Походу я его по пьяни писал.

Tux-oid(*)(2011-10-05 17:18:42)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 17:07:33
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>Кстати там я наткнулся на такой ужаснейший запрос с 2 иннер джойнами и вложенными подзапросами аж 4 уровня выполняющийся больше секунды.
Жуть. У меня на 9.1 оно аж 2,5 сек отрабатывает. Попробовал 8.3 на lenny с сильно загруженным процом - около 3 сек, может оптимизатор со временем урежет. А вообще, конечно, надо на explain смотреть, но я в этом не силён.

SystemV(*)(2011-10-05 17:20:02)

Emacs-w3m/1.4.414 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-05 17:20:02
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Алсо, воткнул глобальный счётчик времени запросов в движок, убедился, что почти 90% времени таки занимают запросы, и пхп совсем не виноват. Если, конечно, с кодом не ошибся.

Вообще там есть простор для денормализации, например для того же самого количества сообщений. Ведь запись тут намного реже чтения, а значит лучше один раз при записи увеличивать счётчик, а не считать его при каждом выводе.

SystemV(*)(2011-10-05 17:25:46)

Emacs-w3m/1.4.414 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 13:07:16
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Если в CPU тогда мож где не прописал индексы и оно скатилось до линейного поиска?

AiFiLTr0(*)(2011-10-05 20:39:51)

Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.30 (KHTML, like Gecko) Ubuntu/11.04 Chromium/12.0.742.112 Chrome/12.0.742.112 Safari/534.30
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от AiFiLTr0 2011-10-05 20:39:51
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Делал полностью REINDEX DATABASE не помогло.

anonymous(*)(2011-10-05 21:30:59)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-05 16:21:08
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Вобщем посмотрел настройки - практически всё тоже что и у меня по дефолту..

Но:

1. shared_buffers=24MB - это в мане советуют выставить в 25% оперативки, но в каком-то референсе по тьюнингу вычитал что увлекаться не стоит и лучше поставить поменьше, например 64MB, и полагаться на кеш, см.ниже:

2. effective_cache_size=128MB - этот параметр советуют выставить в честное значение, обозначающее количество памяти доступной для файлового кеша ОС. Если для твоей домашней машины такое значение более-менее честно, то тут я думаю полгига где-то надо выставить. Ибо "PostgreSQL counts a lot on the OS to cache data files and hence does not bother with duplicating its file caching effort. The shared buffers parameter assumes that OS is going to cache a lot of files and hence it is generally very low compared with system RAM."

anonymous(*)(2011-10-05 21:54:02)
Отредактировано anonymous по причине "не указана"
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 21:54:02
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

... хотя на своей машине не вижу никакого улучшения производительности от задания большего кеша, да и shared_buffers не хочет подниматься выше 27Мб..

anonymous(*)(2011-10-05 23:39:41)

[#] [Добавить метку] [Редактировать] Ответ на: Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-05 12:39:12
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Заменил запрос

sql
SELECT t.id, t.attached, c.subject, c.changing_timest, c.timest FROM threads t INNER JOIN (SELECT tm.tid, tm.subject, tm.timest, max(ch.changing_timest) AS changing_timest FROM comments ch INNER JOIN (SELECT tid, timest, subject FROM comments WHERE timest IN (SELECT min(timest) FROM comments WHERE tid IN (SELECT id FROM threads WHERE section='4' AND subsection='10')  GROUP BY tid)) tm ON ch.tid = tm.tid WHERE ch.tid IN (SELECT id FROM threads WHERE section='4' AND subsection='10')  GROUP BY ch.tid, tm.timest, tm.subject, tm.tid) c ON t.id = c.tid WHERE t.section ='4' AND t.subsection = '10' ORDER BY t.attached <>true ASC, c.timest DESC LIMIT 30 OFFSET 0
 


на

sql
SELECT t.id, t.attached, c.subject, t.changing_timest, t.timest, c.uid FROM threads t INNER JOIN comments c ON t.cid = c.id WHERE t.section ='4' AND t.subsection = '10' ORDER BY t.attached <>true ASC, c.timest DESC LIMIT 30 OFFSET 0
 


и триггер
sql
CREATE OR REPLACE FUNCTION "THREAD_CH_TIMEST_UPDATE"()
  RETURNS TRIGGER AS
$BODY$
DECLARE
ch_timest timestamp without time zone = NEW.changing_timest;
tid INTEGER = NEW.tid;
BEGIN
IF EXISTS (SELECT * FROM threads WHERE id = tid)
THEN
UPDATE threads SET changing_timest = ch_timest WHERE id = tid;
END IF;
RETURN NEW;
END
$BODY$
LANGUAGE 'plpgsql' VOLATILE;

CREATE TRIGGER "THREAD_CH_TIMEST_UPDATE_TRIGGER"
BEFORE INSERT OR UPDATE
ON comments
FOR EACH ROW
EXECUTE PROCEDURE "THREAD_CH_TIMEST_UPDATE"();
 


и время генерации странички со списком тредов сократилось в 2 раза.

Tux-oid(*)(2011-10-06 11:36:10)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-06 11:36:10
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Думаю теперь чем заменить эти 3 запроса.
<!-- Запрос SELECT count(*) AS cnt FROM comments WHERE tid ='34799' выполнен за 0.137907 сек.-->
<!-- Запрос SELECT ALL count(*) AS cnt FROM comments WHERE timest > '2011-10-05 07:37:21' AND tid = '34799' выполнен за 0.049257 сек.-->
<!-- Запрос SELECT ALL count(*) AS cnt FROM comments WHERE timest > '2011-10-06 06:37:21' AND tid = '34799' выполнен за 0.140391 сек.-->

Tux-oid(*)(2011-10-06 11:39:06)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-06 11:39:06
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Второй и третий запросы практически одинаковы, а третий исполнялся втрое дольше - это флуктуация или разница от раза к разу такая?

А для чего тебе эти запросы? Если считаешь сообщения после какого-то заданного, то лучше ориентироваться на ИДы, они в индексе сидят.

anonymous(*)(2011-10-06 12:01:47)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-06 12:01:47
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>это флуктуация или разница от раза к разу такая?
От раза к разу.

>А для чего тебе эти запросы?
Это число ответов всего/день/час в списке тредов. http://rulinux.net/forum_10_page_1

>Если считаешь сообщения после какого-то заданного, то лучше ориентироваться на ИДы, они в индексе сидят.
Тогда придется усложнять запрос еще одной агрегирующей функцией что только замедлит его.

Tux-oid(*)(2011-10-06 12:14:23)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-06 11:39:06
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>Думаю теперь чем заменить эти 3 запроса.
Мне кажется, что тебе надо сделать индексы по timest и tid. Обе эти колонки довольно активно используются в запросах (особенно tid).

Я проверил на глаз, на паре запросов, время заметно уменьшилось.

SystemV(*)(2011-10-06 14:03:11)

Emacs-w3m/1.4.414 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-06 12:14:23
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Фантастика какая-то. И именно в этом порядке?

Попробуй заменить эти три запроса одним (запуск запроса тоже стоит времени сам по себе):

sql
SELECT count(1) AS cnt_all,
       sum(CASE WHEN timest > '2011-10-05 07:37' THEN 1 ELSE 0 END) AS cnt_24h,
       sum(CASE WHEN timest > '2011-10-06 06:37' THEN 1 ELSE 0 END) AS cnt_1h
FROM comments WHERE tid ='34799'
 


Обрати внимание, я ещё секунды из даты убрал. Не знаю осмысленно ли это в случае с постгресом, судя по докам он не должен перепаршивать запросы при изменении параметров, но возможно это позволит ему брать данные прямо из его кеша (от предыдущего такого же запроса) в течение той же минуты. Может есть смысл попробовать и так и так для сравнения.. По функционалу небольшая неточность не должна быть фатальной.

Так же проиндексируй каменты по TID. У тебя выборка каментов обычно идёт в привязке к треду, поэтому такой индекс будет много где полезен, к тому же он обладает хорошей селективностью. Если сейчас РДБМС не имеет никакого представления о каментах и делает фулл-скан по таблице (т.е. перебирает все записи в поисках ну максимум 100 каментов с данным tid, то при наличии индекса объём данных которые ей надо просмотреть уменьшится на порядки).

anonymous(*)(2011-10-06 14:19:06)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-06 14:19:06
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Создал индексы на внешние ключи и на timest и tid. Отпустило.

Tux-oid(*)(2011-10-06 14:26:46)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от SystemV 2011-10-06 14:03:11
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

> Мне кажется, что тебе надо сделать индексы по timest и tid.
Лучше ограничиться tid пока: на каждый тред приходится не так уж много каментов и дополнительно их индексировать ни к чему. А памяти на хосте не вагон - в результате эти индексы со временем перестанут помещаться в системном кеше и из-за лишних индексов, те индексы что действительно необходимы могут оказаться сброшены и за ними придётся ходить на диск.

anonymous(*)(2011-10-06 14:27:05)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-06 14:26:46
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Попробуй теперь убей индекс на timest, убедись что разница ничтожна, потом остальное реализуй тоже: слей всё в один запрос, посмотри разницу, обрежь секунды - снова посмотри.

У тебя ведь эта группа запросов выполняется многократно, так что каждая сэкономленная миллисекунда даст 10-50 сэкономленных миллисекунд на страницу.

anonymous(*)(2011-10-06 14:30:38)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-06 14:30:38
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>слей всё в один запрос, посмотри разницу, обрежь секунды - снова посмотри.
как было <!--Страница сгенерировалась за 0.243588 сек.-->

заменил <!--Страница сгенерировалась за 0.236126 сек.-->

Разницы почти нет.

Tux-oid(*)(2011-10-06 14:44:36)
Отредактировано Tux-oid по причине "не указана"
Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-06 14:27:05
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>Лучше ограничиться tid пока: на каждый тред приходится не так уж много каментов и дополнительно их индексировать ни к чему.
Тоже верно. Правда остаётся трекер, который только по timest-у и ищет.

Если верно влияние секунд в запросах на кэш, то надо их убрать и на трекере.

SystemV(*)(2011-10-06 14:58:32)

Emacs-w3m/1.4.414 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от Tux-oid 2011-10-06 14:44:36
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

Как это нет? Целых 6 миллисекунд! И это на выборке за 3 часа небось? А если кто за больший период смотрит?

А какова получилась разница с индексом по timest и без него?

Ещё вопрос - по старому коду мне показалось ты вызываешь эти запросы для каждого мессажа, попавшего в выблоку, безотносительно того, не были ли те же данные уже вытащены из базы для одного из предыдухи сообщений.. Это так?

anonymous(*)(2011-10-06 14:59:57)

[#] [Добавить метку] [Редактировать] Ответ на: Re:Ну так чо там с апгрейдом постгреса? от anonymous 2011-10-06 14:59:57
avatar
Скрыть

Re:Ну так чо там с апгрейдом постгреса?

>А какова получилась разница с индексом по timest и без него?
без индекса <!--Страница сгенерировалась за 0.599535 сек.-->

с индексом <!--Страница сгенерировалась за 0.542951 сек.-->

>Ещё вопрос - по старому коду мне показалось ты вызываешь эти запросы для каждого мессажа, попавшего в выблоку, безотносительно того, не были ли те же данные уже вытащены из базы для одного из предыдухи сообщений.. Это так?
Они полюбомы не были вытащены ибо эти данные тянутся к списку тредов. А он уникален. Один и тот-же тред в списке не встречается более одного раза.

Tux-oid(*)(2011-10-06 15:11:02)

Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110922 Firefox/7.0 SeaMonkey/2.4
Этот тред читают 1 пользователь:
Анонимных: 1
Зарегистрированных: 0




(c) 2010-2020 LOR-NG Developers Group
Powered by TimeMachine

Valid HTML 4.01 Transitional Правильный CSS!