> 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.
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
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
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():
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
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
> 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
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
for your answer!
--
Kind regards,
Andrey Klychkov
--
--
Kind regards,
Andrey Klychkov
t stage is solving of this issue? Does anybody do it?
Thank you!
--
Kind regards,
Andrey Klychkov
> Понедельник, 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
>Понедельник, 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
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
13 matches
Mail list logo