Re[2]: PGAdmin 4 don't refresh server info after restarting

> You should report this on a pgAdmin mailing list rather than a > PostgreSQL mailing list. Hi, of course, I made a mistake. Thank you for showing me >Вторник, 19 февраля 2019, 19:41 +03:00 от Robert Haas : > >On Mon, Feb 18, 2019 at 1:20 AM Andrey Klychkov < aaklych.

PGAdmin 4 don't refresh server info after restarting

Hello, We've noticed that pgadmin 3.x / 4.x doesn't refresh server info like server version after restarting. It makes people confused. For example, 1. PgAdmin was rinning 2. We upgraded postgres from 11.1 to 11.2 3. PgAdmin was restarted 4. We continued to see 11.1 5. We must push "Disconnect

Re[2]: [PATCH] heap_insert() and heap_update() optimization

yze / checkpoint or something else that could influence on the yesterday tests. Thanks a lot for explanation! >Вторник, 16 октября 2018, 22:57 +03:00 от Andres Freund : > >Hi, > >On 2018-10-16 11:28:17 +0300, Andrey Klychkov wrote: >> I suggest the small attached patch that gi

[PATCH] heap_insert() and heap_update() optimization

Hello, hackers I suggest the small attached patch that gives a bit of heap_insert() and heap_update() optimization by reducing calls of BufferGetPage(buffer) into them. I measured call time of these: heap_insert(): avg origin 13394 ns, avg patched 12685 ns; perf increases +5.59% heap_update():

Re[2]: [PATCH] Change simple_heap_insert() to a macro

nstead of this function. >Пятница, 12 октября 2018, 12:16 +03:00 от Heikki Linnakangas : > >On 12/10/2018 11:54, Andrey Klychkov wrote: >> Studying another question I noticed a small point for optimization. >> >> In the src/backend/access/heap/heapam.c we have the functi

[PATCH] Change simple_heap_insert() to a macro

Hi, Hackers Studying another question I noticed a small point for optimization. In the src/backend/access/heap/heapam.c we have the function: - * simple_heap_insert - insert a tuple - * - * Currently, this routine differs from heap_insert only in supplying - * a default command ID and not

Re[2]: Alter index rename concurrently to

> Attached is an updated patch. That's OK now, the patch applying is without any errors. I have no more remarks. >Пятница, 5 октября 2018, 13:04 +03:00 от Peter Eisentraut >: > >On 03/10/2018 13:51, Andrey Klychkov wrote: >> 1. Patch was applied without any errors

Re[2]: Alter index rename concurrently to

The code structure in >> those two cases make this pretty unlikely even in the future. Also, >> violations would probably be caught by CLOBBER_CACHE_ALWAYS. > >Based on these assertions, here is my proposed patch. It lowers the >lock level for index renaming to ShareUpdateExclusi

Fwd: Re[2]: Alter index rename concurrently to

for your answer! -- Kind regards, Andrey Klychkov -- -- Kind regards, Andrey Klychkov

Re[2]: Alter index rename concurrently to

t stage is solving of this issue? Does anybody do it? Thank you! -- Kind regards, Andrey Klychkov

Re[2]: Alter index rename concurrently to

> Понедельник, 16 июля 2018, 22:19 +03:00 от Andrey Borodin > : > >Hi! > >> 16 июля 2018 г., в 22:58, Andrey Klychkov < aaklych...@mail.ru > написал(а): >> Dear hackers! >> >> I have an idea to facilitate work with index rebuilding. &g

Re[2]: Alter index rename concurrently to

>Понедельник, 16 июля 2018, 22:40 +03:00 от Victor Yegorov : > >пн, 16 июл. 2018 г. в 21:58, Andrey Klychkov < aaklych...@mail.ru >: >>I made a patch to solve this issue (see the attachment). >>It allows to avoid locks by a query like this: >>“alter index re

Alter index rename concurrently to

Dear hackers! I have an idea to facilitate work with index rebuilding. Usually if we want to rebuild an index without table locks we should do the queries below: 1. create index concurrently... (with different name on the same columns) 2. drop index concurrently 3. alter index rename to As