On Fri, Apr 5, 2019 at 8:41 PM Alvaro Herrera wrote:
>
> Is 0001 a bugfix?
Yep, it is rather a bugfix and can be applied independently.
The fix allocates temporary strings using temporary context
Conf->buildCxt.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgr
Is 0001 a bugfix?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 25.02.2019 14:33, Arthur Zakirov wrote:
It seems to me Tom and Andres also vote for the mmap() approach. I think
I need to look closely at the mmap().
I've labeled the patch as 'v13'.
Unfortunately I didn't come up with a new patch yet. So I marked the
entry as "Returned with feedback" for
On 21.02.2019 19:13, Robert Haas wrote:
So I think it's better to have each backend locally make a decision
about when that particular backend no longer needs the dictionary, and
then let the system automatically clean up the ones that are needed by
nobody.
Yep, it wouldn't be hard to implement
On February 21, 2019 10:08:00 AM PST, Tom Lane wrote:
>Robert Haas writes:
>> Perhaps a better approach still would be to do what Andres proposed
>> back in March:
>
>> #> Is there any chance we can instead can convert dictionaries into a
>form
>> #> we can just mmap() into memory? That'd sca
Robert Haas writes:
> Perhaps a better approach still would be to do what Andres proposed
> back in March:
> #> Is there any chance we can instead can convert dictionaries into a form
> #> we can just mmap() into memory? That'd scale a lot higher and more
> #> dynamicallly?
That seems awfully a
On Thu, Feb 21, 2019 at 8:28 AM Arthur Zakirov wrote:
> Your approach looks simpler. It is necessary just to periodically scan
> dictionaries' cache hash table and not call dsm_pin_segment() when a DSM
> segment initialized. It also means that a dictionary is loaded into DSM
> only while there is
On 21.02.2019 15:45, Robert Haas wrote:
On Wed, Feb 20, 2019 at 9:33 AM Arthur Zakirov wrote:
I'm working on the (b) approach. I thought about a priority queue
structure. There no such ready structure within PostgreSQL sources
except binaryheap.c, but it isn't for concurrent algorithms.
I don
On Wed, Feb 20, 2019 at 9:33 AM Arthur Zakirov wrote:
> I'm working on the (b) approach. I thought about a priority queue
> structure. There no such ready structure within PostgreSQL sources
> except binaryheap.c, but it isn't for concurrent algorithms.
I don't see why you need a priority queue o
Hello,
I've created the new commitfest entry since the previous entry was
closed with status "Returned with feedback":
https://commitfest.postgresql.org/22/2007/
I attached new version of the patch. There are changes only in
0003-Retrieve-shared-location-for-dict-v18.patch.
I added a refer
Hi,
On 2019-02-01 09:40:44 -0500, Robert Haas wrote:
> On Tue, Jan 22, 2019 at 2:17 PM Tomas Vondra
> wrote:
> > I think there are essentially two ways:
> >
> > (a) Define max amount of memory available for shared dictionarires, and
> > come up with an eviction algorithm. This will be tricky, bec
On Tue, Jan 22, 2019 at 2:17 PM Tomas Vondra
wrote:
> I think there are essentially two ways:
>
> (a) Define max amount of memory available for shared dictionarires, and
> come up with an eviction algorithm. This will be tricky, because when
> the frequently-used dictionaries need a bit more memor
On 01.02.2019 12:09, Arthur Zakirov wrote:
Thanks for sharing your ideas, Tomas. Unfortunately I won't manage to
develop new version of the patch till the end of the commitfest due to
lack of time. I'll think about the second approach. Tracking timestamp
of the last time a dict was used may be
On 22.01.2019 22:17, Tomas Vondra wrote:
On 1/22/19 7:36 PM, Arthur Zakirov wrote:
max_shared_dictionaries_size can be renamed to
shared_dictionaries_cleanup_threshold.
That really depends on what exactly the threshold does. If it only
triggers cleanup but does not enforce maximum amount of me
On 1/22/19 7:36 PM, Arthur Zakirov wrote:
> пн, 21 янв. 2019 г. в 19:42, Arthur Zakirov :
>>
>> On 21.01.2019 17:56, Tomas Vondra wrote:
>>> I wonder if we could devise some simple cache eviction policy. We don't
>>> have any memory limit GUC anymore, but maybe we could use unload
>>> dictionari
пн, 21 янв. 2019 г. в 19:42, Arthur Zakirov :
>
> On 21.01.2019 17:56, Tomas Vondra wrote:
> > I wonder if we could devise some simple cache eviction policy. We don't
> > have any memory limit GUC anymore, but maybe we could use unload
> > dictionaries that were unused for sufficient amount of time
On 21.01.2019 17:56, Tomas Vondra wrote:
On 1/21/19 12:51 PM, Arthur Zakirov wrote:
I'll try to implement the syntax, you suggested earlier:
ALTER TEXT SEARCH DICTIONARY x UNLOAD/RELOAD
The main point here is that UNLOAD/RELOAD can't release the memory
immediately, because some other backend m
On 1/21/19 12:51 PM, Arthur Zakirov wrote:
> On 21.01.2019 02:43, Tomas Vondra wrote:
>> On 1/20/19 11:21 PM, Andres Freund wrote:
>>> On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
Thanks. I've reviewed v17 today and I haven't discovered any new issues
so far. If everything goes fine
On 21.01.2019 02:43, Tomas Vondra wrote:
On 1/20/19 11:21 PM, Andres Freund wrote:
On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
Thanks. I've reviewed v17 today and I haven't discovered any new issues
so far. If everything goes fine and no one protests, I plan to get it
committed over the n
On 1/20/19 11:21 PM, Andres Freund wrote:
> On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
>> On 1/17/19 3:15 PM, Arthur Zakirov wrote:
>>> I attached files of new version of the patch, I applied your tweaks.
>>>
XXX All dictionaries, but only when there's invalid dictionary?
>>>
>>> I've m
On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
> On 1/17/19 3:15 PM, Arthur Zakirov wrote:
> > I attached files of new version of the patch, I applied your tweaks.
> >
> >> XXX All dictionaries, but only when there's invalid dictionary?
> >
> > I've made a little optimization. I introduced has
On 1/17/19 3:15 PM, Arthur Zakirov wrote:
> I attached files of new version of the patch, I applied your tweaks.
>
>> XXX All dictionaries, but only when there's invalid dictionary?
>
> I've made a little optimization. I introduced hashvalue into
> TSDictionaryCacheEntry. Now released only DSM of
I attached files of new version of the patch, I applied your tweaks.
> XXX All dictionaries, but only when there's invalid dictionary?
I've made a little optimization. I introduced hashvalue into
TSDictionaryCacheEntry. Now released only DSM of altered or dropped
dictionaries.
> > /* XXX no
Hello Tomas,
On 16.01.2019 03:23, Tomas Vondra wrote:
I've looked at the patch today, and in general is seems quite solid to
me. I do have a couple of minor points
1) I think the comments need more work. Instead of describing all the
individual changes here, I've outlined those improvements in
Hello Arthur,
I've looked at the patch today, and in general is seems quite solid to
me. I do have a couple of minor points
1) I think the comments need more work. Instead of describing all the
individual changes here, I've outlined those improvements in attached
patches (see the attached "tweaks
On 01.10.2018 12:22, Arthur Zakirov wrote:
On Thu, Jun 14, 2018 at 11:40:17AM +0300, Arthur Zakirov wrote:
I attached new version of the patch.
The patch still applies to HEAD. I moved it to the next commitfest.
Here is the rebased patch. I also updated copyright in ts_shared.h and
ts_shar
On Thu, Jun 14, 2018 at 11:40:17AM +0300, Arthur Zakirov wrote:
> I attached new version of the patch.
The patch still applies to HEAD. I moved it to the next commitfest.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
On Wed, May 16, 2018 at 02:36:33PM +0300, Arthur Zakirov wrote:
> ... I attached the rebased patch.
I attached new version of the patch.
I found a bug when CompoundAffix,
SuffixNodes, PrefixNodes, DictNodes of IspellDictData structure are
empty. Now they have terminating entry and therefore they
On Thu, May 17, 2018 at 02:14:07PM -0400, Robert Haas wrote:
> On Thu, May 17, 2018 at 1:52 PM, Tom Lane wrote:
> > Do we actually need to worry about unmapping promptly on DROP TEXT
> > DICTIONARY? It seems like the only downside of not doing that is that
> > we'd leak some address space until p
On Thu, May 17, 2018 at 10:18:56AM -0400, Tom Lane wrote:
> I think the point you've not addressed is that "syscache callback
> occurred" does not equate to "object was dropped". Can the code
> survive having this occur at any invalidation point?
> (CLOBBER_CACHE_ALWAYS testing would soon expose a
On Thu, May 17, 2018 at 1:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote:
>>> I think the point you've not addressed is that "syscache callback
>>> occurred" does not equate to "object was dropped". Can the code
>>> survive having this occur at
Robert Haas writes:
> On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote:
>> I think the point you've not addressed is that "syscache callback
>> occurred" does not equate to "object was dropped". Can the code
>> survive having this occur at any invalidation point?
>> (CLOBBER_CACHE_ALWAYS testing
On Thu, May 17, 2018 at 10:18 AM, Tom Lane wrote:
> Robert Haas writes:
>> ... Assuming that we can
>> convince ourselves that that much is OK, I don't see why using a
>> syscache callback to help ensure that the mappings are blown away in
>> an at-least-somewhat-timely fashion is worse than any
On Thu, May 17, 2018 at 09:57:59AM -0400, Robert Haas wrote:
> I think you and Tom have misunderstood each other somehow. If you
> look at CommitTransaction(), you will see a comment that says:
Oh, I understood. You are right.
> Also, there is no absolute prohibition on kernel calls in post-comm
Robert Haas writes:
> ... Assuming that we can
> convince ourselves that that much is OK, I don't see why using a
> syscache callback to help ensure that the mappings are blown away in
> an at-least-somewhat-timely fashion is worse than any other approach.
I think the point you've not addressed i
On Wed, May 16, 2018 at 4:42 PM, Arthur Zakirov
wrote:
> I haven't deep knowledge about guts of invalidation callbacks. It seems
> that there is problem with it. Tom pointed above:
>
>> > I'm not sure that I understood the second case correclty. Can cache
>> > invalidation help in this case? I don
On Wed, May 16, 2018 at 09:33:46AM -0400, Robert Haas wrote:
> > In sum, I think the problem is mostly solved. Backend 2 unpins the
> > segment in next ts_lexize() call. But if backend 2 doesn't call
> > ts_lexize() (or other TS function) anymore the segment will remain mapped.
> > It is the only p
On Wed, May 16, 2018 at 7:36 AM, Arthur Zakirov
wrote:
>> I don't quite understand the problem you're trying to solve here, but:
>>
>> 1. Unless dsm_pin_segment() is called, a DSM segment will
>> automatically be removed when there are no remaining mappings.
>>
>> 2. Unless dsm_pin_mapping() is ca
Hello,
On Tue, May 15, 2018 at 05:02:43PM -0400, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 8:19 AM, Arthur Zakirov
> wrote:
> > Yes, there is dsm_pin_mapping() for this. But it is necessary to keep a
> > segment even if there are no attached processes. From 0003:
> >
> > + /* Remain atta
On Tue, Mar 27, 2018 at 8:19 AM, Arthur Zakirov
wrote:
>> I assume the DSM infrastructure already has some solution for getting
>> rid of DSM segments when the last interested process disconnects,
>> so maybe you could piggyback on that somehow.
>
> Yes, there is dsm_pin_mapping() for this. But it
On Thu, Mar 29, 2018 at 02:03:07AM +0300, Arthur Zakirov wrote:
> Here is the new version of the patch.
Please find the attached new version of the patch.
I removed refcnt because it is useless, it doesn't guarantee that a hash
table entry will be removed.
I fixed a bug, dsm_unpin_segment() can
Tomas Vondra wrote:
>
> On 03/31/2018 12:42 PM, Arthur Zakirov wrote:
> > Hello all,
> >
> > I'd like to add new optional function to text search template named fini
> > in addition to init() and lexize(). It will be called by
> > RemoveTSDictionaryById() and AlterTSDictionary(). dispell_fini() wil
On 03/31/2018 12:42 PM, Arthur Zakirov wrote:
> Hello all,
>
> I'd like to add new optional function to text search template named fini
> in addition to init() and lexize(). It will be called by
> RemoveTSDictionaryById() and AlterTSDictionary(). dispell_fini() will
> call ts_dict_shmem_release(
Hello all,
I'd like to add new optional function to text search template named fini in
addition to init() and lexize(). It will be called by
RemoveTSDictionaryById() and AlterTSDictionary(). dispell_fini() will call
ts_dict_shmem_release().
It doesn't change segments leaking situation. I think it
Here is the new version of the patch.
Now RemoveTSDictionaryById() and AlterTSDictionary() unpin the
dictionary DSM segment. So if all attached backends disconnect allocated
DSM segments will be released.
lookup_ts_dictionary_cache() may unping DSM mapping for all invalid
dictionary cache entries
Please find the attached new version of the patch.
I got rid of 0005 and 0006 parts. There are no
max_shared_dictionaries_size variable, Shareable option,
pg_ts_shared_dictionaries view anymore.
On Sat, Mar 24, 2018 at 04:56:36PM -0400, Tom Lane wrote:
> I do think it's required that changing the
On Mon, Mar 26, 2018 at 11:27:48AM -0400, Tom Lane wrote:
> Arthur Zakirov writes:
> > I'm not sure that I understood the second case correclty. Can cache
> > invalidation help in this case? I don't have confident knowledge of cache
> > invalidation. It seems to me that InvalidateTSCacheCallBack()
Arthur Zakirov writes:
> On Sun, Mar 25, 2018 at 12:18:10AM -0400, Tom Lane wrote:
>> My thought was (a) the ROLLBACK case is ok, because the next use of
>> the dictionary will reload it, and (b) the reload-concurrently-with-
>> DROP case is annoying, because indeed it leaks, but the window is sma
On Sun, Mar 25, 2018 at 02:28:29PM -0400, Tom Lane wrote:
> Arthur Zakirov writes:
> > If all dictionaries will be shareable then this view could be removed.
> > Unfortunately I think it can't help with leaked segments, I didn't find
> > a way to iterate dshash entries. That's why pg_ts_shared_dic
On Sun, Mar 25, 2018 at 12:18:10AM -0400, Tom Lane wrote:
> My thought was (a) the ROLLBACK case is ok, because the next use of
> the dictionary will reload it, and (b) the reload-concurrently-with-
> DROP case is annoying, because indeed it leaks, but the window is small
> and it probably won't be
Arthur Zakirov writes:
> On Sat, Mar 24, 2018 at 04:56:36PM -0400, Tom Lane wrote:
>> * And that leads us to not particularly need a view telling which
>> dictionaries are loaded, either. It's just an implementation detail
>> that users don't need to worry about.
> If all dictionaries will be sh
On Sun, Mar 25, 2018 at 06:45:08AM +0200, Tomas Vondra wrote:
> FWIW this is where the view listing dictionaries loaded into shared
> memory would be helpful - you'd at least know there's a dictionary,
> wasting memory.
Unfortunately, It seems that this view can't help in listing leaked
segments.
On Sat, Mar 24, 2018 at 04:56:36PM -0400, Tom Lane wrote:
> Arthur Zakirov writes:
> > [ v10 patch versions ]
Thank you for the review, Tom!
Tomas Vondra wrote:
> Tom Lane wrote:
>> * I cannot imagine a use-case for setting max_shared_dictionaries_size
>> to anything except "unlimited". If it's
Tomas Vondra writes:
> FWIW this is where the view listing dictionaries loaded into shared
> memory would be helpful - you'd at least know there's a dictionary,
> wasting memory.
Well, that's only because we failed to make the implementation transparent
:-(. But it's not unlikely that an mmap-ba
On 03/25/2018 06:18 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 3/24/18 9:56 PM, Tom Lane wrote:
>>> Also, the scheme for releasing the dictionary DSM during
>>> RemoveTSDictionaryById is uncertain and full of race conditions:
>>> the DROP might roll back later, or someone might come along
Tomas Vondra writes:
> On 3/24/18 9:56 PM, Tom Lane wrote:
>> Also, the scheme for releasing the dictionary DSM during
>> RemoveTSDictionaryById is uncertain and full of race conditions:
>> the DROP might roll back later, or someone might come along and
>> start using the dictionary (causing a fre
On 3/24/18 9:56 PM, Tom Lane wrote:
> Arthur Zakirov writes:
>> [ v10 patch versions ]
>
> I took a quick look through this. I agree with the comments about
> mmap-ability not being something we should insist on now, and maybe
> not ever. However, in order to keep our options open, it seems l
Arthur Zakirov writes:
> [ v10 patch versions ]
I took a quick look through this. I agree with the comments about
mmap-ability not being something we should insist on now, and maybe
not ever. However, in order to keep our options open, it seems like
we should minimize the amount of API we expos
On Wed, Mar 21, 2018 at 12:00:52PM +0300, Arthur Zakirov wrote:
> On Tue, Mar 20, 2018 at 09:30:15PM +0100, Tomas Vondra wrote:
> > I wonder if these restrictions needed? I mean, why not to allow setting
> > max_shared_dictionaries_size below the size of loaded dictionaries?
> >
> > Of course, on
On Tue, Mar 20, 2018 at 09:30:15PM +0100, Tomas Vondra wrote:
> On 03/20/2018 02:11 PM, Arthur Zakirov wrote:
> > max_shared_dictionaries_size is defined as PGC_SIGHUP now. Added check
> > of a new value to disallow to set zero if there are loaded dictionaries
> > and to decrease maximum allowed si
On 03/20/2018 02:11 PM, Arthur Zakirov wrote:
> Hello,
>
> On Mon, Mar 19, 2018 at 08:50:46PM +0100, Tomas Vondra wrote:
>> Hi Arthur,
>>
>> I went through the patch - just skimming through the diffs, will do more
>> testing tomorrow. Here are a few initial comments.
>
> Thank you for the revie
Hello,
On Mon, Mar 19, 2018 at 08:50:46PM +0100, Tomas Vondra wrote:
> Hi Arthur,
>
> I went through the patch - just skimming through the diffs, will do more
> testing tomorrow. Here are a few initial comments.
Thank you for the review!
> 1) max_shared_dictionaries_size / PGC_POSTMASTER
>
> I
Hi Arthur,
I went through the patch - just skimming through the diffs, will do more
testing tomorrow. Here are a few initial comments.
1) max_shared_dictionaries_size / PGC_POSTMASTER
I'm not quite sure why the GUC is defined as PGC_POSTMASTER, i.e. why it
can't be changed after server start. Th
On Mon, Mar 19, 2018 at 07:40:54PM +0100, Tomas Vondra wrote:
>
>
> On 03/19/2018 07:07 PM, Andres Freund wrote:
> > You've to manually configure a setting that can only be set at server
> > start. You can't set it as big as necessary because it might use up
> > memory better used for other thin
On 03/19/2018 07:07 PM, Andres Freund wrote:
> On 2018-03-19 14:52:34 +0100, Tomas Vondra wrote:
>> On 03/19/2018 02:34 AM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2018-03-19 01:52:41 +0100, Tomas Vondra wrote:
I do agree with that. We have a working well-understood dsm-based
solution,
On 2018-03-19 14:52:34 +0100, Tomas Vondra wrote:
> On 03/19/2018 02:34 AM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-03-19 01:52:41 +0100, Tomas Vondra wrote:
> >> I do agree with that. We have a working well-understood dsm-based
> >> solution, addressing the goals initially explained in this
On 03/19/2018 02:34 AM, Andres Freund wrote:
> Hi,
>
> On 2018-03-19 01:52:41 +0100, Tomas Vondra wrote:
>> I do agree with that. We have a working well-understood dsm-based
>> solution, addressing the goals initially explained in this thread.
>
> Well, it's also awkward and manual to use. I do t
On Mon, 19 Mar 2018 14:06:50 +0300
Arthur Zakirov wrote:
>
> I beleive mmap requires completely rewrite 0003 part of the patch and
> a little changes in 0005.
>
> > In any case, I suggest to polish the dsm-based patch, and see if we
> > can get that one into PG11.
>
> Yes we have more time i
Arthur Zakirov wrote:
> I've planned only to improve the documentation a little. Also it seems I
> should change 0004 part, I found that extension upgrade scripts may be made
> in wrong way.
I've attached new version of the patch. In this version I removed
0004-Update-tmplinit-arguments-v6.patch.
Hi,
On 2018-03-19 01:52:41 +0100, Tomas Vondra wrote:
> I do agree with that. We have a working well-understood dsm-based
> solution, addressing the goals initially explained in this thread.
Well, it's also awkward and manual to use. I do think that's something
we've to pay attention to.
> I wo
On 03/17/2018 05:43 AM, Arthur Zakirov wrote:
> Hello Tomas,
>
> Arthur, what are your plans with this patch in the current CF?
>
>
> I think dsm-based approach is in good shape already and works nice.
> I've planned only to improve the documentation a little. Also it seems I
> should change
Hello Tomas,
Arthur, what are your plans with this patch in the current CF?
I think dsm-based approach is in good shape already and works nice.
I've planned only to improve the documentation a little. Also it seems I
should change 0004 part, I found that extension upgrade scripts may be made
in
On 03/07/2018 02:18 PM, Arthur Zakirov wrote:
> On Wed, Mar 07, 2018 at 02:12:32PM +0100, Pavel Stehule wrote:
>> 2018-03-07 14:10 GMT+01:00 Pavel Stehule :
>>> 2018-03-07 13:58 GMT+01:00 Arthur Zakirov :
Oh understood. Tomas suggested those commands too earlier. I'll
implement them. But
On Wed, Mar 07, 2018 at 02:12:32PM +0100, Pavel Stehule wrote:
> 2018-03-07 14:10 GMT+01:00 Pavel Stehule :
> > 2018-03-07 13:58 GMT+01:00 Arthur Zakirov :
> >> Oh understood. Tomas suggested those commands too earlier. I'll
> >> implement them. But I think it is better to track files modification
2018-03-07 14:10 GMT+01:00 Pavel Stehule :
>
>
> 2018-03-07 13:58 GMT+01:00 Arthur Zakirov :
>
>> On Wed, Mar 07, 2018 at 01:47:25PM +0100, Pavel Stehule wrote:
>> > > Do you mean that a shared dictionary should be reloaded if its .affix
>> > > and .dict files was changed? IMHO we can store last m
2018-03-07 13:58 GMT+01:00 Arthur Zakirov :
> On Wed, Mar 07, 2018 at 01:47:25PM +0100, Pavel Stehule wrote:
> > > Do you mean that a shared dictionary should be reloaded if its .affix
> > > and .dict files was changed? IMHO we can store last modification
> > > timestamp of them in a preprocessed
On Wed, Mar 07, 2018 at 01:47:25PM +0100, Pavel Stehule wrote:
> > Do you mean that a shared dictionary should be reloaded if its .affix
> > and .dict files was changed? IMHO we can store last modification
> > timestamp of them in a preprocessed file, and then we can rebuild the
> > dictionary if f
2018-03-07 13:43 GMT+01:00 Arthur Zakirov :
> On Wed, Mar 07, 2018 at 01:02:07PM +0100, Pavel Stehule wrote:
> > > Understand. I'm not againts the mmap() approach, just I have lack of
> > > understanding mmap() benefits... Current shared Ispell approach
> requires
> > > preprocessing after server
On Wed, Mar 07, 2018 at 01:02:07PM +0100, Pavel Stehule wrote:
> > Understand. I'm not againts the mmap() approach, just I have lack of
> > understanding mmap() benefits... Current shared Ispell approach requires
> > preprocessing after server restarting, and the main advantage of mmap()
> > here
>
2018-03-07 12:55 GMT+01:00 Arthur Zakirov :
> On Wed, Mar 07, 2018 at 10:55:29AM +0100, Tomas Vondra wrote:
> > On 03/07/2018 09:55 AM, Arthur Zakirov wrote:
> > > Hello Andres,
> > >
> > > On Thu, Mar 01, 2018 at 08:31:49PM -0800, Andres Freund wrote:
> > >> Is there any chance we can instead can
On Wed, Mar 07, 2018 at 10:55:29AM +0100, Tomas Vondra wrote:
> On 03/07/2018 09:55 AM, Arthur Zakirov wrote:
> > Hello Andres,
> >
> > On Thu, Mar 01, 2018 at 08:31:49PM -0800, Andres Freund wrote:
> >> Is there any chance we can instead can convert dictionaries into a form
> >> we can just mmap(
On 03/07/2018 09:55 AM, Arthur Zakirov wrote:
> Hello Andres,
>
> On Thu, Mar 01, 2018 at 08:31:49PM -0800, Andres Freund wrote:
>> Is there any chance we can instead can convert dictionaries into a form
>> we can just mmap() into memory? That'd scale a lot higher and more
>> dynamicallly?
>
>
Hello Andres,
On Thu, Mar 01, 2018 at 08:31:49PM -0800, Andres Freund wrote:
> Is there any chance we can instead can convert dictionaries into a form
> we can just mmap() into memory? That'd scale a lot higher and more
> dynamicallly?
To avoid misunderstanding can you please elaborate on using
On Wed, Feb 07, 2018 at 07:28:29PM +0300, Arthur Zakirov wrote:
> Here is rebased version of the patch due to changes into dict_ispell.c.
> The patch itself wasn't changed.
Here is rebased version of the patch due to changes within pg_proc.h.
I haven't implemented a mmap prototype yet, though.
--
Hello,
Thank you for your comments.
On Thu, Mar 01, 2018 at 08:31:49PM -0800, Andres Freund wrote:
> Hi,
>
> On 2018-02-07 19:28:29 +0300, Arthur Zakirov wrote:
> > + {
> > + {"max_shared_dictionaries_size", PGC_POSTMASTER, RESOURCES_MEM,
> > + gettext_noop("Sets th
Hi,
On 2018-02-07 19:28:29 +0300, Arthur Zakirov wrote:
> + {
> + {"max_shared_dictionaries_size", PGC_POSTMASTER, RESOURCES_MEM,
> + gettext_noop("Sets the maximum size of all text search
> dictionaries loaded into shared memory."),
> + get
On Thu, Jan 25, 2018 at 07:51:58PM +0300, Arthur Zakirov wrote:
> Attached new version of the patch.
Here is rebased version of the patch due to changes into dict_ispell.c.
The patch itself wasn't changed.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Compa
Hello,
Thank you for your review! Good catches.
On Thu, Jan 25, 2018 at 03:26:46PM +0300, Ildus Kurbangaliev wrote:
> In 0001 there are few lines where is only indentation has changed.
Fixed.
> 0002:
> - TsearchShmemSize - calculating size using hash_estimate_size seems
> redundant since you us
On Wed, 24 Jan 2018 20:20:41 +0300
Arthur Zakirov wrote:
Hi, I did some review of the patch.
In 0001 there are few lines where is only indentation has changed.
0002:
- TsearchShmemSize - calculating size using hash_estimate_size seems
redundant since you use DSA hash now.
- ts_dict_shmem_releas
2018-01-24 20:57 GMT+03:00 Tomas Vondra :
>
> Thanks. I don't have time to review/test this before FOSDEM, but a
> couple of comments regarding some of the points you mentioned.
>
Thank you for your thoughts.
> > I thought about it. And it seems to me that we can use functions
> > ts_unload() an
Hi,
On 01/24/2018 06:20 PM, Arthur Zakirov wrote:
> On Sat, Jan 13, 2018 at 06:22:41PM +0300, Arthur Zakirov wrote:
>> I think your proposals may be implemented in several patches, so
>> they can be applyed independently but consistently. I suppose I
>> will prepare new version of the patch with f
On Sat, Jan 13, 2018 at 06:22:41PM +0300, Arthur Zakirov wrote:
> I think your proposals may be implemented in several patches, so they can
> be applyed independently but consistently. I suppose I will prepare new
> version of the patch with fixes and with initial design of new functions
> and comm
On 01/15/2018 08:02 PM, Arthur Zakirov wrote:
> On Sat, Jan 13, 2018 at 10:33:14PM +0100, Tomas Vondra wrote:
>> Not sure if we really need to add the database/schema OIDs. I mentioned
>> the unexpected consequences (cross-db sharing) but maybe that's a
>> feature we should keep (it reduces memory
On Sat, Jan 13, 2018 at 10:33:14PM +0100, Tomas Vondra wrote:
> Not sure if we really need to add the database/schema OIDs. I mentioned
> the unexpected consequences (cross-db sharing) but maybe that's a
> feature we should keep (it reduces memory usage). So perhaps this should
> be another CREATE
On 01/13/2018 04:22 PM, Arthur Zakirov wrote:
> Hello,
>
> Thank you Tomas for your review.
>
> On Sat, Jan 13, 2018 at 03:25:55AM +0100, Tomas Vondra wrote:
>> allocate memory in the buildCxt. What about adding tmpstrdup to copy a
>> string into the context? I admit this is mostly nitpicking t
Hello,
Thank you Tomas for your review.
On Sat, Jan 13, 2018 at 03:25:55AM +0100, Tomas Vondra wrote:
> allocate memory in the buildCxt. What about adding tmpstrdup to copy a
> string into the context? I admit this is mostly nitpicking though.
I agree about tmpstrdup(). It will be self consisten
Hi Arthur,
I've done some initial review of the patch today, and here are some
thoughts:
0001-Fix-ispell-memory-handling-v2.patch
This makes sense. The patch simply replaces two cpstrdup() calls with
MemoryContextStrdup, but I see spell.c already has two macros to
allocate memory in the buildCxt
Thank you for your answer.
On Mon, Jan 08, 2018 at 06:12:37PM +0100, Tomas Vondra wrote:
>
> I believe Pavel was referring to this extension:
>
> https://github.com/tvondra/shared_ispell
>
Oh, understood.
> I wasn't going to submit that as in-core solution, but I'm happy you're
> making i
Hi Arthur,
Sorry for the delay, I somehow missed this thread ...
On 12/27/2017 10:20 AM, Arthur Zakirov wrote:
> On Tue, Dec 26, 2017 at 07:03:48PM +0100, Pavel Stehule wrote:
>>
>> Tomas had some workable patches related to this topic
>>
>
> Tomas, have you planned to propose it?
>
I believe
On Sun, Dec 31, 2017 at 06:28:13PM +0300, Arthur Zakirov wrote:
>
> There are issues to do:
> - add the GUC-variable for hash table limit
> - fix bugs
> - improve comments
> - performance testing
>
Here is the second version of the patch.
0002-Retreive-shmem-location-for-ispell-v2.patch:
Fixed
1 - 100 of 107 matches
Mail list logo
