some working with bgworker it disconnects from mqs and the
worker becomes free for another backend. So the workers can act like a
cache, or keep some long connections with other services and so on.
--
---
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
On Wed, 1 Nov 2017 17:05:58 -0400
Peter Eisentraut wrote:
> On 9/12/17 10:55, Ildus Kurbangaliev wrote:
> >> The patch also includes custom compression method for tsvector
> >> which is used in tests.
> >>
> >> [1]
> >> https://www.postg
On Thu, 2 Nov 2017 23:02:34 +0800
Craig Ringer wrote:
> On 2 November 2017 at 17:41, Ildus Kurbangaliev
> wrote:
>
> > In this patch compression methods is suitable for MAIN and EXTENDED
> > storages like in current implementation in postgres. Just instead
> > only
ating functions that can be used to
build tsvectors. There were duplicated code fragments in places where
tsvector was built.
Also new patch frees some space in WordEntry that can be used to
save some additional information about saved words.
-
---
Ildus Kurbangaliev
Postgres Professional: http:/
x27;m not familiar with pg_upgrade, but want to ask: should this
> workaround be part of pg_upgrade?
>
> Greetings,
> Torsten
I chose the way when the data remains the same, until the user decides
to update it. I'm not so familiar with pg_upgrade myself and I don't
see now
; src/tools/pgindent/README. (If you find any portability problems
> while trying to install pgindent, please let me know.)
Attached a new version of the patch. It mostly contains cosmetic
changes. I rebased it to current master, ran pgindent and fixed
formatting errors.
--
---
Ildus Kurba
ecific tests performance regression about 15%.
Same time I think this could be the worst case, because usually data
is on disk and conversion will not affect so much to performance.
--
---
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
quot;, File: "trigger.c", Line: 2428)
I'm not sure how it should be fixed, because as I see `oldtuple` will
be set only for AFTER ROW triggers by `wholerow` junk attribute.
Regards,
Ildus Kurbangaliev
test.sql
Description: application/sql
--
Sent via pgsql-hackers mailing list (pg
` called only for parent
relation, so there is no `wholerow` attribute for foreign tables.
--
---
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 15 May 2017 17:43:52 +0530
Ashutosh Bapat wrote:
> On Mon, May 15, 2017 at 2:46 PM, Ildus Kurbangaliev
> wrote:
> > On Mon, 15 May 2017 10:34:58 +0530
> > Dilip Kumar wrote:
> >
> >> On Sun, May 14, 2017 at 9:54 PM, Dilip Kumar
> >> wrot
On Tue, 16 May 2017 15:21:27 +0530
Ashutosh Bapat wrote:
> On Mon, May 15, 2017 at 7:24 PM, Ildus Kurbangaliev
> wrote:
> > On Mon, 15 May 2017 17:43:52 +0530
> > Ashutosh Bapat wrote:
> >
> >> On Mon, May 15, 2017 at 2:46 PM, Ildus Kurbangaliev
> >&g
On Tue, 16 May 2017 21:36:11 +0900
Etsuro Fujita wrote:
> On 2017/05/16 21:11, Ashutosh Bapat wrote:
> > On Tue, May 16, 2017 at 5:35 PM, Ildus Kurbangaliev
> > wrote:
>
> >> I agree. Maybe this issue should be added to Postgresql Open Items?
> >>
On Wed, 17 May 2017 15:28:24 +0900
Michael Paquier wrote:
> On Tue, May 16, 2017 at 11:26 PM, Ildus Kurbangaliev
> wrote:
> > On Tue, 16 May 2017 21:36:11 +0900
> > Etsuro Fujita wrote:
> >> On 2017/05/16 21:11, Ashutosh Bapat wrote:
> >> >
27;ll add this to the next commitfest.
>
> Best regards,
> Etsuro Fujita
>
> [1]
> https://www.postgresql.org/message-id/20170514150525.0346ba72%40postgrespro.ru
Checked the latest patch. Looks good.
Shouldn't this patch be backported to 9.6 and 10beta? The bug
affects them too
On Thu, 7 Sep 2017 23:08:14 +0200
Tomas Vondra wrote:
> Hi,
>
> On 08/17/2017 12:23 PM, Ildus Kurbangaliev wrote:
> > In my benchmarks when database fits into buffers (so it's
> > measurement of the time required for the tsvectors conversion) it
> > gives me
objections, so I removed the const-expression
> > simplification from the patch and I added the note to the docs for
> > AddForeignUpdateTargets.
> >
> > Attached is an updated version of the patch.
>
> I cleaned up the patch a bit. PFA a new version of t
event from pg_stat_activity;
pid | wait_event
---+--
17099 | LWLocks: BufferCleanupLock
17100 | Locks: Transaction
17101 | LWLocks: BufferPartitionLock
17102 |
17103 | Network: READ
17086 |
(6 rows)
--
Ildus Kurbangaliev
Postgres Professional:
On 07/21/2015 01:18 PM, Andres Freund wrote:
On 2015-07-21 13:11:36 +0300, Ildus Kurbangaliev wrote:
/*
* Top-level transactions are identified by VirtualTransactionIDs comprising
diff --git a/src/include/storage/lwlock.h b/src/include/storage/lwlock.h
index cff3b99..55b0687 100644
On 07/22/2015 09:10 AM, Kyotaro HORIGUCHI wrote:
Hello,
At Tue, 21 Jul 2015 14:28:25 +0300, Ildus Kurbangaliev
wrote in <55ae2cd9.4050...@postgrespro.ru>
On 07/21/2015 01:18 PM, Andres Freund wrote:
On 2015-07-21 13:11:36 +0300, Ildus Kurbangaliev wrote:
/*
* Top
On 07/23/2015 05:57 AM, Kyotaro HORIGUCHI wrote:
At Wed, 22 Jul 2015 17:50:35 +0300, Ildus Kurbangaliev
wrote in<55afadbb.9090...@postgrespro.ru>
>On 07/22/2015 09:10 AM, Kyotaro HORIGUCHI wrote:
> >Hello,
> >
> >At Tue, 21 Jul 2015 14:28:25 +0300, Ildus
s for LWLocks that are not individual is obtained from
corresponding tranches.
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
extend_pg_stat_activity_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-ha
> On Jul 24, 2015, at 7:26 AM, Amit Kapila wrote:
>
> On Fri, Jul 24, 2015 at 12:31 AM, Ildus Kurbangaliev
> wrote:
> Hello.
> I’ve changed the previous patch. `group` field in LWLock is removed, so the
> size of LWLock will not increase.
> Instead of the `group
d lock.c, and can be used for other things (for example
tracing). One byte sounds good only for this case. We are going to extend
waits monitoring, add more views, some profiling. That’s why waits have to be
groupable by classes.
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.c
Hello.
In the attached patch I've made a refactoring for tranches.
The prefix for them was extended, and I've did a split of LWLockAssign
to two
functions (one with tranche and second for user defined LWLocks).
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgresp
On 07/28/2015 10:28 PM, Heikki Linnakangas wrote:
On 07/27/2015 01:20 PM, Ildus Kurbangaliev wrote:
Hello.
In the attached patch I've made a refactoring for tranches.
The prefix for them was extended, and I've did a split of LWLockAssign
to two
functions (one with tranche and secon
On 08/03/2015 04:25 PM, Ildus Kurbangaliev wrote:
On 07/28/2015 10:28 PM, Heikki Linnakangas wrote:
On 07/27/2015 01:20 PM, Ildus Kurbangaliev wrote:
Hello.
In the attached patch I've made a refactoring for tranches.
The prefix for them was extended, and I've did a split of LWLoc
idual LWLock and forgets to add its name. Code
generation
is also a solution, and if commiters will support it I'll merge it to
main patch.
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-ha
d you could have a runtime check that complains
> if there's an entry missing, like Ildus did in his latest patch.
>
> I have no particular objection to your perl script either, though. I'll leave
> it up to you.
>
> - Heikki
>
A new version
On 08/04/2015 11:47 PM, Robert Haas wrote:
On Tue, Aug 4, 2015 at 4:37 PM, Ildus Kurbangaliev
wrote:
A new version of the patch. I used your idea with macros, and with tranches that
allowed us to remove array with names (they can be written directly to the
corresponding
tranche).
You seem
On 08/05/2015 09:33 PM, Robert Haas wrote:
On Wed, Aug 5, 2015 at 1:10 PM, Ildus Kurbangaliev
wrote:
About `memcpy`, PgBackendStatus struct already have a bunch of multi-byte
variables, so it will be
not consistent anyway if somebody will want to copy it in that way. On the
other hand two
Hello hackers!This patch contains LWLocks changes from pg_stat_activity thread(http://www.postgresql.org/message-id/flat/ca+tgmoyd3gtz2_mjfuhf+rpe-bcy75ytjekvv9x-o+soncg...@mail.gmail.com/)and I think it deserves a separate thread.The goal is to split LWLocks from one array to logical pieces (with
On Sep 6, 2015, at 2:36 PM, and...@anarazel.de wrote:On 2015-09-05 12:48:12 +0300, Ildus Kurbangaliev wrote:Another parts require a some discussion so I didn't touch them yet.At this point I don't see any point in further review until these areaddressed.The idea to create an individua
On Sun, 6 Sep 2015 23:18:02 +0200
"and...@anarazel.de" wrote:
> On 2015-09-06 22:57:04 +0300, Ildus Kurbangaliev wrote:
> > Ok, I've kept only one tranche for individual LWLocks
>
> But you've added the lock names as a statically sized array to all
> tranch
at_report_wait_event(WaitEvent_OtherTrancheLWLock);
}
can be changed to something like:
#define LWLOCK_WAIT_ID(lock) \
(lock->tranche == 0? T_ID(lock) : lock->tranche +
NUM_INDIVIDUAL_LWLOCKS)
static void
LWLockReportStat(LWLock *lock)
{
int offset = ;
pgstat_report_wait_event(offset + LWLOCK_WAIT_ID(lock));
}
So it will almost not affect to performance of LWLockAcquire.
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
<http://www.postgrespro.com/> The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that PostgreSQL has
> > tolerated all kinds of loads we have thrown at it.
>
> Can anyone on hackers answer this question from June?
>
Hi, I'm working on patch now that removes this limit without changes (or
small changes) of on-disk layout. I think it'll be ready duri
e is
two API calls (for a size determination and a tranche creation), except
MainLWLockArray is used only for individual LWLocks.
Also I suggest to keep RequestAddinLWLocks for backward compatibility.
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com <http://www.postgrespro.com/>
The Russian Postgres Company
Added changes related to the latest master (for individual LWLocks
definitions)
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
lwlocks_refactor_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
> On Sep 13, 2015, at 11:32 PM, Robert Haas wrote:
>
> On Sun, Sep 13, 2015 at 12:43 PM, Ildus Kurbangaliev
> wrote:
>> Added changes related to the latest master (for individual LWLocks
>> definitions)
>
> If I haven't said this clearly enough already, I&#
On Mon, 14 Sep 2015 06:32:22 -0400
Robert Haas wrote:
> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
> wrote:
> > Yes, that is because I tried to go with current convention working
> > with shmem in Postgres (there are one function that returns the
> > size an
On Tue, 15 Sep 2015 14:39:51 -0400
Robert Haas wrote:
> On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev
> wrote:
> > On Mon, 14 Sep 2015 06:32:22 -0400
> > Robert Haas wrote:
> >
> >> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
> >> wro
On Wed, 23 Sep 2015 11:46:00 -0400
Robert Haas wrote:
> On Wed, Sep 23, 2015 at 11:22 AM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> On Tue, Sep 22, 2015 at 5:16 AM, Ildus Kurbangaliev
> >> wrote:
> >> > Yes, probably.
> >> >
On 11/06/2015 08:53 PM, Robert Haas wrote:
On Fri, Nov 6, 2015 at 6:27 AM, Ildus Kurbangaliev
wrote:
There is a patch that splits SLRU LWLocks to separate tranches and
moves them to SLRU Ctl. It does some work from the main patch from
this thread, but can be commited separately. It also
> On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote:
>
> Ildus Kurbangaliev wrote:
>
>> Thanks for the review. I've attached a new version of SLRU patch. I've
>> removed add_postfix and fixed EXEC_BACKEND case.
>
> Thanks.
>
> Please do not use
On 11/09/2015 10:32 PM, Ildus Kurbangaliev wrote:
On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote:
Ildus Kurbangaliev wrote:
Thanks for the review. I've attached a new version of SLRU patch. I've
removed add_postfix and fixed EXEC_BACKEND case.
Thanks.
Please do not use &qu
On Thu, 12 Nov 2015 14:59:59 -0500
Robert Haas wrote:
> On Wed, Nov 11, 2015 at 6:50 AM, Ildus Kurbangaliev
> wrote:
> > Attached a new version of the patch that moves SLRU tranches and LWLocks to
> > SLRU control structs.
> >
> > `buffer_locks` field now conta
control struct in shared memory like in other places?
BufferDescriptors
and BufferBlocks can be kept there along with tranches definitions
and lwlocks. Buffer locks that are located in MainLWLockArray by offset
can be moved there too.
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgresp
On Mon, 16 Nov 2015 18:55:55 -0500
Robert Haas wrote:
> On Mon, Nov 16, 2015 at 7:32 AM, Ildus Kurbangaliev
> wrote:
> > What if just create a control struct in shared memory like in other places?
> > BufferDescriptors
> > and BufferBlocks can be kept there along w
> On 2015-11-17 14:14:50 +0300, Ildus Kurbangaliev wrote:
> > 1) We can avoid constants, and use a standard steps for tranches
> > creation.
>
> The constants are actually a bit useful, to easily determine
> builtin/non-builtin stuff.
Maybe I'm missing something her
On Thu, 19 Nov 2015 11:09:38 -0500
Robert Haas wrote:
> On Thu, Nov 19, 2015 at 9:04 AM, Ildus Kurbangaliev
> wrote:
> > The moving base tranches to shared memory has been discussed many
> > times. The point is using them later in pg_stat_activity and other
> > monitori
On Mon, 23 Nov 2015 12:12:23 -0500
Robert Haas wrote:
> On Fri, Nov 20, 2015 at 6:53 AM, Ildus Kurbangaliev
> wrote:
> > We keep limited number of LWLocks in base shared memory, why not
> > keep their thanches in shared memory too? Other tranches can be in
> > local memo
/* Extract entries of tsvector */
res = toast_decompress_datum_partial(attr, evh->data,
evh->dcState, sizeof(int32) + sizeof(WordEntry) * evh->count);
if (res == -1)
elog(ERROR, "compressed tsvector is corrupted");
--
On Fri, 4 Dec 2015 22:13:58 +0900
Michael Paquier wrote:
> On Fri, Dec 4, 2015 at 9:47 PM, Ildus Kurbangaliev
> wrote:
> > Attached patch adds support of partial decompression for datums.
> > It will be useful in many cases when extracting part of data is
> > enough fo
On Sat, 5 Dec 2015 06:14:07 +0900
Michael Paquier wrote:
> On Sat, Dec 5, 2015 at 12:10 AM, Simon Riggs
> wrote:
> > On 4 December 2015 at 13:47, Ildus Kurbangaliev
> > wrote:
> >
> >>
> >> Attached patch adds support of partial decompression for da
aximum is
> 0xffff
>
There is a more improved version of the patch. Main idea is to present
uuid as two uint64 values, and make comparisons and penalty calculation
based on these values. This approach is much faster than using memcmp
for uuid comparisons.
--
ere every lock in the system has a
> descriptive name, either via the tranche or because it's an
> individually named lock, which sounds excellent.
>
There is a patch that moves backend LWLocks into PGPROC and to a
separate tranche. I did tests, and it doesn't regress and the
On Wed, 23 Dec 2015 16:36:23 -0800
Paul Jungwirth wrote:
> On 12/23/2015 08:10 AM, Ildus Kurbangaliev wrote:
> > There is a more improved version of the patch. Main idea is to
> > present uuid as two uint64 values, and make comparisons and penalty
> > calculation based
}
>
> First, variables (high and low) should not be declared in the middle
> of code. Second, assert will fail if ua.v64[0] == ub.v64[0] and
> ua.v64[1] > ub.v64[1] although it's a possible and allowed case.
> Third, actually you multiply high value by 2^64 anf low by 2^-64.
&
WRITE| 18339 | 0 | 0 | 0 | 0 | 0
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/pg_stat_wait/Makefile b/contrib/pg_stat_wait/Makefile
new file mode 100644
index 000..16ad170
--- /dev/null
+++ b/contrib/
> On Jul 9, 2015, at 5:18 PM, Fujii Masao wrote:
>
> On Thu, Jul 9, 2015 at 2:12 PM, Haribabu Kommi <mailto:kommi.harib...@gmail.com>> wrote:
>> On Thu, Jul 9, 2015 at 1:52 AM, Ildus Kurbangaliev
>> wrote:
>>> Hello.
>>>
>>> Currentl
s to your patch, so we can later
extend it with our other modifications. Main issue is that one variable
for all types is not enough. For flexibity in the future we need at
least two - class and event, for example class=LWLock,
event=ProcArrayLock, or class=Storage, and event=READ. With this
modification it is not so big problem merge our patches to one. There
are not so many types of waits, they can fit to one int32 and can be
read atomically too.
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
rs of wait.
Other problem of pg_stat_activity that we can not see all processes
there (checkpointer for example). So we anyway need separate view for
monitoring purposes.
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-ha
> On Jul 14, 2015, at 5:25 PM, Tom Lane wrote:
>
> Robert Haas writes:
>> I really think we should do the simple thing first. If we make this
>> complicated and add lots of bells and whistles, it is going to be much
>> harder to get anything committed, because there will be more things
>> for
62 matches
Mail list logo
