> 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 fro
tovacuum / analyze / 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 attache
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(): av
ed macro instead 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
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 allowing
> 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 error
ot used across possible relcache reloads. 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 l
d it.
Ok, Peter, thanks for your answer!
--
Kind regards,
Andrey Klychkov
------
--
Kind regards,
Andrey Klychkov
x27;concurrent' field in the RenameStmt
structure.
However, the "concurrently" keyword is realized there for index renaming only
because I only see need to rename indexes in concurrent mode.
It also may be implemented for tables, etc if it will be really needed for
someone in the future.
--
Kind regards,
Andrey Klychkov
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.
>>
>
>Понедельник, 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 you
14 matches
Mail list logo
