Hi, Justin!
Thank you for revising documentation patch.
On Mon, May 7, 2018 at 7:55 PM, Justin Pryzby <pry...@telsasoft.com> wrote:
> On Mon, May 07, 2018 at 07:26:25PM +0300, Alexander Korotkov wrote:
> > Hi!
> >
> > I've revised docs and comments, and also made some
-comments-fixes.patch
Documentation and comment improvements from Justin Pryzby
revised by me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
0001-vacuum-cleanup-index-scale-factor-user-set.patch
Description: Binary data
0002-vacuum
;
>> HINT: Valid units for this parameter are "kB", "MB", "GB", and "TB".
>>
>> This time the hint is accurate, but why is "B" not accepted here? Seems
>> inconsistent.
>>
>
> Here's a pretty straightforward fix for these two issues. Any objections
> or better ideas?
This patch looks good for me.
But I would also like to see units in valid range message (as I wrote in
previous email).
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
now?
>
Yes, I think "B" should be mentioned in hint.
Testing a setting with GUC_UNIT_KB:
>
> $ postmaster -c work_mem=102400B
> FATAL: invalid value for parameter "work_mem": "10B"
> HINT: Valid units for this parameter are "kB", "MB", "GB", and "TB".
>
> This time the hint is accurate, but why is "B" not accepted here? Seems
> inconsistent.
+1
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
t;
Thank you for clarifying this point. We've missed that.
Perhaps there is a case for adding an additional flag to allow specifying
> "I can't support ORDER BY DESC", but I'm not in a big hurry to do so.
> I think there would be more changes than this needed to handle suc
{"kB", GUC_UNIT_XBLOCKS, -(XLOG_BLCKSZ / 1024)},
> > + {"B", GUC_UNIT_XBLOCKS, -(XLOG_BLCKSZ / (1024 * 1024))},
>
> Same?
>
As I understand, in these cases multiplier should be just -BLCKSZ and
-XLOG_BLCKSZ correspondingly.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, May 16, 2018 at 4:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > On Wed, May 16, 2018 at 1:41 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> Perhaps there is a case for adding an additional flag
gt;
> New large features are not appropriate for the July CF. September should
> be your goal.
Assuming this, should we have possibility to register patch to
September CF from now?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
t;. If AM with given name already exists in pg_am,
why should we ignore the error?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Jun 14, 2018 at 1:01 AM Peter Geoghegan wrote:
> On Mon, Jun 11, 2018 at 9:30 AM, Alexander Korotkov
> wrote:
> > On Mon, Jun 11, 2018 at 1:06 PM Simon Riggs wrote:
> >> It's a good idea. How does it perform with many duplicate entries?
>
> I agr
r it on commitfest. If even there wouldn't be enough
of time for this patch on July commitfest, it's no problem to move it.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
on 2nd page of
> pending list and deleted.
Is this test case completed? It looks like there should be a
continuation with concurrent vacuum and insertions managed by gdb...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
very.
> >
> > I think we should complaint "recovery is in progress" error in this
> > case rather than erroring due to lock modes.
> +1
+1,
but current behavior doesn't seem to be bug, but rather not precise
enough error reporting. So, I think we shouldn't conside
(1, 100);
>
> Similar code in PLyMapping_ToJsonbValue() seems to be correct because
> PyList_GetItem() and PyTuple_GetItem() return a borrowed reference.
>
> Patch with fix is attached.
I'm going to check and commit this if everything is OK.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Jun 14, 2018 at 6:32 PM Peter Geoghegan wrote:
> On Thu, Jun 14, 2018 at 5:43 AM, Alexander Korotkov
> wrote:
> > However, that doesn't
> > look like inevitable shortcoming, because we could store heap TID in
> > t_tid of pivot index tuples.
>
> But the of
pendently on
whether we're keeping duplicates ordered by TID or not.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
y short period of time (a
> little over 24 hours) because of the specific circumstances: I knew
> that the doc section was not well considered in the first place, I
> thought that the question was clear cut, and I doubted that anyone
> else would follow up at all.
FWIW, I've no
qual
to 1.1. But as Darafei claimed, 100 maximum value is probably too low
for advanced users, who really need benefits of this optimization.
So, I'm proposing to raise maximum valus of
vacuum_cleanup_index_scale_factor to DBL_MAX. Any objections?
--
Alexander Korotkov
Postgres Prof
On Tue, Jun 19, 2018 at 6:18 PM Daniel Gustafsson wrote:
> > On 19 Jun 2018, at 12:40, Alexander Korotkov
> > wrote:
> >
> > On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
> > wrote:
> >> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa&qu
On Tue, Jun 19, 2018 at 12:25 PM Masahiko Sawada wrote:
> On Tue, Jun 19, 2018 at 5:43 PM, Alexander Korotkov
> wrote:
> > On Tue, Jun 19, 2018 at 11:34 AM Masahiko Sawada
> > wrote:
> >> On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov
> >> > S
On Tue, Jun 19, 2018 at 11:34 AM Masahiko Sawada wrote:
> On Mon, Jun 18, 2018 at 1:56 PM, Alexander Korotkov
> > So, I'm proposing to raise maximum valus of
> > vacuum_cleanup_index_scale_factor to DBL_MAX. Any objections?
> >
>
> I agree to expand the maximum val
t_insertonpg, the upgrade is done inside the
> critical section. It seems the above cases are missed.
>
> 3.
> + TransactionId btm_oldest_btpo_xact; /* oldest btpo_xact among of
> +* deleted pages */
>
> /among of/among all
>
> Atta
On Sat, Jun 2, 2018 at 12:05 AM Tom Lane wrote:
> The core team is pleased to announce the appointment of seven
> new Postgres committers:
>
> Etsuro Fujita
> Peter Geoghegan
> Amit Kapila
> Alexander Korotkov
> Thomas Munro
> Michael Paquier
> Tomas Vondra
>
&
got more
confident that providing
separate paths for incremental sorts is right. In the next revision of
this patch, incremental
sort paths would be provided in more cases.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
implemented by Alexander Korotkov.
> This patch prevents granting of shared lock if wait queue is not empty.
> May be we should use this patch or find some other way to prevent starvation
> of writers on relation extension locks for such workloads.
Fair lwlock patch really fixed starvatio
On Tue, Jun 26, 2018 at 1:46 PM Masahiko Sawada wrote:
> On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov
> wrote:
> > So, I propose to just
> > increase maximum value for both GUC and reloption. See the attached
> > patch. It also changes calculations
I doubt
it should be backpatched, especially if we will accept the new lock
level. We should rather apply patch to the documentation of supported
versions, which would claim that vacuum can still cancel queries on
standbys regardless hot_standby_feedback option.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Jun 20, 2018 at 8:32 AM Masahiko Sawada wrote:
> On Wed, Jun 20, 2018 at 1:00 AM, Alexander Korotkov
> > Ok. I've rephrased comment a bit. Also, you created "index vacuum"
> > subsection in the "resource usage" section. I think it's
On Tue, Jun 26, 2018 at 4:11 PM Darafei "Komяpa" Praliaskouski
wrote:
> вт, 26 июн. 2018 г. в 15:42, Alexander Korotkov :
>>
>> On Tue, Jun 26, 2018 at 1:46 PM Masahiko Sawada
>> wrote:
>> > On Fri, Jun 22, 2018 at 6:55 PM, Alexander Korotkov
&
Also isnull property of SpGistSearchItem doesn't
have comment.
* I think KNN support should be briefly described in
src/backed/access/spgist/README.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
first btcleanup() call when no tuples were deleted. Second and
subsequent btcleanup() calls may skip index scan. This aspect needs
to be properly documented.
I'm going to propose a patch for this subject in a couple of days.
That patch would incorporate some of your changes as well as contain
some changes from me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
and then src/backend/access/
> for things which are specific to a particular AM.
I would vote for the first proposal: table AM. Because we eventually
might get index-organized tables whose don't have something like heap.
So, it would be nice to avoid hardcoding "heap" name.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
nate O(N^2) scaling from rw-conflict tracking in serializable
transactions (2017)
* Foreign keys for Array elements (2017)
And subject of one project wasn't listed in our ideas list (parallel copy
with error handling).
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Jan 4, 2018 at 8:03 AM, Haribabu Kommi <kommi.harib...@gmail.com>
wrote:
> On Thu, Jan 4, 2018 at 10:00 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Wed, Jan 3, 2018 at 10:08 AM, Haribabu Kommi <kommi.harib...@gmail.com
>> >
On Wed, Dec 13, 2017 at 2:13 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Dec 12, 2017 at 2:33 PM, Teodor Sigaev <teo...@sigaev.ru> wrote:
>
>> 0002-pg-trgm-strict_word-similarity.patch – implementation of
>>> strict_word_similarit
On Fri, Dec 8, 2017 at 4:06 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Thank you for pointing that. Sure, both cases are better. I've added
> second case as well as comments. Patch is attached.
>
I just found that patch apply is failed according to commitf
On Mon, Jan 8, 2018 at 2:29 PM, Antonin Houska <a...@cybertec.at> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> wrote:
>
> > Antonin Houska <a...@cybertec.at> wrote:
>
> > > Shouldn't the test contain *both* cases?
>
> > Thank you f
ery). I
> think, just words is enough.
I found that cube_2.out expected output in regression tests is used on
Windows 2003 in my virtual machine. I've checked that for both cube
patches, regression tests pass correctly on that virtual machine.
--
Alexander Korotkov
Postgres
l enough. The fact remains that we can't check
> very well for functions; maybe suggest a LIKE clause to look for ~>
> anywhere in function source code?
>
That's an option, but we should note that this check is inexact.
(It looks like you could get rid of the 'deptype' qual and
> de
Hi!
On Mon, Dec 4, 2017 at 6:42 PM, Pavel Stehule <pavel.steh...@gmail.com>
wrote:
> 2017-12-04 9:29 GMT+01:00 Alexander Korotkov <a.korot...@postgrespro.ru>:
>
>> On Mon, Dec 4, 2017 at 11:21 AM, Alexander Korotkov <
>> a.korot...@postgrespro.ru> wrote:
er thing is that it's probably hard to do in our current
optimizer/executor/am
infrastructure. And assuming that use-case is quite narrow, and it looks
OK to just disable such feature as bug fix.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
riable naming, formatting,
comments.
BTW, do we really need to set shouldCount depending on whether we receive
stats argument or not? What if we always set shouldCount as in the first
branch of "if"?
> shouldCount = !heap_attisnull(rel->rd_indextuple, Anum_pg_index_indpred) ||
eview this
patch.
My first note on this patchset is following. These patches touches
sensitive aspects or GiST and are related to complex concurrency issues.
Thus, I'm sure both of them deserve high-level description in
src/backend/access/gist/README. Given this description, it would be much
easier t
Hi!
On Fri, Jan 5, 2018 at 5:26 AM, Stephen Frost <sfr...@snowman.net> wrote:
> * Alexander Korotkov (a.korot...@postgrespro.ru) wrote:
> > On Thu, Jan 4, 2018 at 11:36 PM, Stephen Frost <sfr...@snowman.net>
> wrote:
> > > * Stephen Frost (sfr...@snowman
e a valid approach to mitigate this problem meantime.
Experimental research on this subject is required before considering
committing any patches though.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Jan 20, 2018 at 4:24 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Fri, Sep 29, 2017 at 8:20 PM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > On Fri, Sep 8, 2017 at 4:07 AM, Thomas Munro <
> thomas.mu...@enterprisedb.com>
g strange.
I've contacted Shubham using Telegram, and we realized that
it's because he used tab width 8 in his editor.
Shumham seems to have updated version of this patch, but didn't
post it yet. Thus, I'm marking this "Waiting on author" until
the updated patch is posted.
--
Al
On Thu, Jan 25, 2018 at 5:13 PM, Shubham Barai <shubhambara...@gmail.com>
wrote:
>
>
> On 25 January 2018 at 18:40, Alexander Korotkov <a.korot...@postgrespro.ru
> > wrote:
>
>> On Wed, Jan 10, 2018 at 9:55 PM, Shubham Barai <shubhambara...@gmail.com>
>&g
depending objects before entension
upgrade. Anyway, assuming that behavior of ~> operator was changed,
depending
objects need to be adjusted not just rebuilt. So, magic would unlikely
work in
this case.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
I'm concerning about its compatibility with
pluggable table access methods API. Does zheap use table AM API from this
thread? Or does it just override current heap and needs to be adopted to
use table AM API? Or does it implements own API?
*Links*
1. https://wiki.postgresql.org/wiki/FOSDEM/PG
t;
> Please please note that the attached patch is *NOT* meant to be a full
> proposal or even a to be reviewed patch, it's just an illustration of
> the concepts I'm talking about.
>
> Comments? Better ideas?
>
As I get, your primary interest in this topic is vectorized executi
On Fri, Feb 23, 2018 at 2:20 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Feb 16, 2018 at 5:56 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > BTW, EnterpriseDB announces zheap table access method (heap with undo
> log)
> > [2]. I thi
t;
>
> Apart from rebase to the latest master code, following are the additional
> changes,
>
> 1. Added API for bulk insert and rewrite functionality(Logical rewrite is
> not touched yet)
> 2. Tuple lock API interface redesign to remove the traversal logic from
>
es happens to everybody.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
eg'::text) AND (author ~<~
'Greh'::text))
(8 rows)
So, I think in principle optimizer is capable to handle such kind of
queries (pgsql 9.6.6).
Did you try setting enable_seqscan = off? Probably, something is wrong
with costing in this case...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
tch added two copies of the poly_ops row to the "Built-in SP-GiST
> Operator Classes" table in spgist.sgml.
Right.
> The attached patched removes
> one of them.
>
Thank for fixing this! I'm sure that Teodor will push this after end of
New Year holidays in Russia.
--
Alex
On Wed, Jan 3, 2018 at 10:08 AM, Haribabu Kommi <kommi.harib...@gmail.com>
wrote:
>
> On Wed, Dec 27, 2017 at 11:33 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>>
>> Also, I appreciate that now tuple_insert() and tuple_update() methods ar
Z - CHKSUMSZ) in
order to evade typing it multiple times.
2. You also didn't modify all the SLRU macros depending on useful size of
page. You missed at least COMMIT_TS_XACTS_PER_PAGE,
MULTIXACT_MEMBERGROUPS_PER_PAGE and SUBTRANS_XACTS_PER_PAGE.
3. pg_upgrade isn't considered. This patch should prov
On Tue, Jun 19, 2018 at 1:40 PM Alexander Korotkov
wrote:
> On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
> wrote:
> > On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
> > wrote:
> > >>
> > >> > I'm not sure it is useful
On Tue, Jun 19, 2018 at 12:15 PM Alexander Korotkov
wrote:
> On Sat, Jun 16, 2018 at 3:57 PM Darafei "Komяpa" Praliaskouski
> wrote:
> >>
> >> > I'm not sure it is usefull in release notes since it is more about API,
> >> > and not
> >>
On Wed, Jun 20, 2018 at 12:00 PM Alexander Korotkov
wrote:
> On Wed, Jun 20, 2018 at 8:32 AM Masahiko Sawada wrote:
> > On Wed, Jun 20, 2018 at 1:00 AM, Alexander Korotkov
> > > Ok. I've rephrased comment a bit. Also, you created "index vacuum"
> > > subse
On Wed, Aug 1, 2018 at 3:17 PM Arthur Zakirov wrote:
> On Mon, Jul 23, 2018 at 05:21:43PM +0300, Alexander Korotkov wrote:
> > Thank you, Arthur. These examples shows downside of this patch, where
> > users may be faced with incompatibility. But it's good that this
> > sit
On Thu, Aug 2, 2018 at 6:17 PM Alexander Korotkov
wrote:
> After some experiments I found that when you mix spaces and separators
> between two fields, then Oracle takes into account only length of last
> group of spaces/separators.
>
> # SELECT to_timestamp('2018- -01 02', '
Hi!
On Thu, Jul 26, 2018 at 1:31 PM Imai, Yoshikazu
wrote:
> On Wed, July 25, 2018 at 0:28 AM, Alexander Korotkov wrote:> > On Tue, Jul
> 10, 2018 at 4:39 PM 今井 良一 wrote:
> > I've reread the thread. And I found that in my initial letter [1] I
> > forget to include inde
consideration in next 24 hours.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, Jul 27, 2018 at 12:30 AM Simon Riggs wrote:
> On 26 July 2018 at 20:59, Alexander Korotkov
> wrote:
>
> > Great, thank you! So, I think the regression is demystified. We can
> > now conclude that on our benchmarks this patch doesn't cause
> > perform
On Fri, Jul 27, 2018 at 6:11 PM Alexander Korotkov
wrote:
> On Fri, Jul 27, 2018 at 12:30 AM Simon Riggs wrote:
> > On 26 July 2018 at 20:59, Alexander Korotkov
> > wrote:
> >
> > > Great, thank you! So, I think the regression is demystified. We can
> > &
://www.postgresql.org/message-id/CAPpHfdso_Yvbo-EXKD8t3cuAeR7wszPyuWNBdjQLi1NrMt3O5w%40mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ownside is inability to truncate the heap.
So, options are good if they provide workaround for users, but that
shouldn't stop us from fixing issues around heap truncation.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Aug 16, 2018 at 4:57 PM Liudmila Mantrova
wrote:
> On 08/14/2018 06:38 PM, Alexander Korotkov wrote:
> > On Thu, Aug 2, 2018 at 9:06 PM Alexander Korotkov
> > wrote:
> > BTW, I've also revised documentation and regression tests. Patch is
> > attached.
> &g
EXMBYT05
2.
https://www.postgresql.org/message-id/CAPpHfdsytkTFMy3N-zfSo+kAuUx=u-7jg6q2byb6fpuw2cd...@mail.gmail.com
3.
https://www.postgresql.org/message-id/CAPpHfdt_HFxNKFbSUaDg5QHxzKcvPBB5OhRengRpVDp6ubdrFg%40mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
On Fri, Aug 10, 2018 at 8:08 AM Masahiko Sawada
wrote:
> I found that the release note says "Add pgtrgm function
> strict_word_similarity() to compute the similarity of whole words" but
> I think "pgtrgm" should be "pg_trgm". Attached patch fixes it.
>
f the disk access."
This sentence doesn't look correct for me. Cost of the disk access is
estimated inside amcostestimate(). As I get, indexPages is used to
estimate how effective parallel scan would be, because different
workers pick different leaf pages. I'm going to adjust this sentence
an
On Fri, Aug 10, 2018 at 1:37 PM Alexander Korotkov
wrote:
> On Fri, Aug 10, 2018 at 6:24 AM Tatsuro Yamada
> wrote:
> >
> > Attached patch for fixing documents of "61.2. Index Access Method
> > Functions" and
> > "61.6. Index Cost Estimation F
Hi!
On Thu, Aug 9, 2018 at 11:26 PM Ivan Kartyshov
wrote:
> Alexander Korotkov писал 2018-06-20 20:54:
> > Thinking about that more I found that adding vacuum mark as an extra
> > argument to LockAcquireExtended is also wrong. It would be still hard
> > to determine if w
Hi!
On Fri, Aug 10, 2018 at 5:07 PM Alexander Korotkov
wrote:
> On Thu, Aug 9, 2018 at 11:26 PM Ivan Kartyshov
> wrote:
> > Alexander Korotkov писал 2018-06-20 20:54:
> > > Thinking about that more I found that adding vacuum mark as an extra
> > > argument to Loc
On Thu, Aug 2, 2018 at 9:06 PM Alexander Korotkov
wrote:
> On Thu, Aug 2, 2018 at 6:17 PM Alexander Korotkov
> wrote:
> > After some experiments I found that when you mix spaces and separators
> > between two fields, then Oracle takes into account only length of last
&
On Thu, Aug 16, 2018 at 2:16 PM Alexander Korotkov
wrote:
> On Tue, Aug 14, 2018 at 12:05 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Feb 28, 2018 at 11:24 PM, Ivan Kartyshov
> > wrote:
> > > The main goal of my changes is to let long read-only
On Fri, Aug 17, 2018 at 6:41 PM Andres Freund wrote:
> On 2018-08-17 11:35:40 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2018-08-17 18:00:20 +0300, Alexander Korotkov wrote:
> > >> So, do we have any objections to committing this?
> >
> >
On Fri, Aug 17, 2018 at 8:38 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Fri, Aug 17, 2018 at 6:41 PM Andres Freund wrote:
> >> There's another patch, which I thought Alexander was referring to, that
> >> does something a bit smarger. On a super short skim
ffers.
Any thoughts?
Links.
1.
https://www.postgresql.org/message-id/flat/5BBC590AE8DF4ED1A170E4D48F1B53AC%40tunaPC
2.
https://www.postgresql.org/message-id/flat/CAHGQGwE5UqFqSq1%3DkV3QtTUtXphTdyHA-8rAj4A%3DY%2Be4kyp3BQ%40mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
That is, if ftruncate
> fails, handle it by zeroing the undeletable pages and pressing on?
I've just started really digging into this set of problems. But this
idea looks good for me so soon...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
eroing of to-be-truncated blocks
to be catastrophic for performance? Or something else?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
builtin
dictionaries and configurations. So, I think this patch should also
split builtin dictionaries into stemmers and stop word dictionaries,
and provide corresponding configuration over them. It would be also
needed to perform some benchmarking to show that new way of defining
configurations is not
On Tue, Aug 21, 2018 at 4:10 PM Alexander Korotkov
wrote:
> After reading [1] and [2] I got that there are at least 3 different
> issues with heap truncation:
> 1) Data corruption on file truncation error (explained in [1]).
> 2) Expensive scanning of the whole shared buffers
On Fri, Aug 24, 2018 at 1:13 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Fri, Apr 6, 2018 at 10:52 AM Aleksandr Parfenov
> > wrote:
> >> The key point of the patch is to process stopwords the same way as
> >> others at the level of the Po
essage-id/CAPpHfdu6Wm4DSAp8Pvwq0uo7fCSzsbrNy7x2v5EKK_g4Nkjx1Q%40mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
_ctl logrotate. I wonder how
that would work on Windows. Thankfully commitfest.cputube.org have
Windows checking facility now.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
pg_ctl_logrotate_v6.patch
Description: Binary data
n = CUBE_MAX_DIM;
> You wanted larger cube, but got cube of another dimension.
>
> I think we should something like this
OK, but I think cube_c_f8() and cube_c_f8_f8() also need to be
revised. Also, I think this behavior should be covered by regression
tests.
--
Alexander Korotkov
Hi!
On Wed, Aug 29, 2018 at 5:05 AM Kyotaro HORIGUCHI
wrote:
> At Tue, 28 Aug 2018 18:50:31 +0300, Alexander Korotkov
> wrote in
>
> > Also I found that this new pg_ctl isn't covered with tests at all. So
> > I've added very simple tap tests, which ensures that when log
On Fri, Aug 17, 2018 at 9:55 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Fri, Aug 17, 2018 at 8:38 PM Tom Lane wrote:
> >> Alexander Korotkov writes:
> >>> Yes, that's correct. On standby read-only queries can tolerate
> >>> c
Hi!
Thank you for feedback.
On Sun, Aug 26, 2018 at 4:09 AM Robert Haas wrote:
> On Tue, Aug 21, 2018 at 9:10 AM, Alexander Korotkov
> wrote:
> > After heap truncation using this algorithm, shared buffers may contain
> > past-OEF buffers. But those buffers are em
onfig, assuming that it can be
actually a dictionary nay.
+ if (fout->remoteVersion >= 11)
PostgreSQL 11 already passed feature freeze. Thus, we should be aimed to
PostgreSQL 12.
That's all for now, but I'm going to do more detailed code review.
--
Alexander Korotkov
Postgr
rect. I'll review it in more details and commit.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Jul 8, 2018 at 12:15 AM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sat, Jul 7, 2018 at 12:31 AM Tom Lane wrote:
> > Alexander Korotkov writes:
> > > I tool a look at this patch. It looks good for me. It applies
> > > cleanly on las
ining WAL. But despite being faster it would still
consume way more overall I/O resources. I'm not sure if we should
provide some option to switch between WAL methods (or heuristics)...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Jul 22, 2018 at 6:22 PM David G. Johnston
wrote:
> On Sat, Jul 21, 2018 at 2:34 PM, Alexander Korotkov
> wrote:
>>
>> So, as I get from this thread, current patch brings these function very
>> close to Oracle behavior. The only divergence found yet is
> =# SELECT TO_TIMESTAMP('2011y5m1d', 'tMMtDDt');
> to_timestamp
>
> 2011-05-01 00:00:00+04
Thank you, Arthur. These examples shows downside of this patch, where
users may be faced with incompatibility. But it's good that this
situation can
sage-id/flat/CA%2BTgmoYd3GTz2_mJfUHF%2BRPe-bCy75ytJeKVv9x-o%2BSonCGApw%40mail.gmail.com
3.
https://www.postgresql.org/message-id/flat/CAG95seUAQVj09KzLwU%2Bz1B-GqdMqerzEkPFR3hn0q88XzMq-PA%40mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi!
On Mon, Jul 2, 2018 at 3:56 PM Ildus Kurbangaliev
wrote:
> On Mon, 18 Jun 2018 17:30:45 +0300
> Ildus Kurbangaliev wrote:
>
> > On Tue, 24 Apr 2018 14:05:20 +0300
> > Alexander Korotkov wrote:
> >
> > >
> > > Yes, this patch definitely lack
1 - 100 of 1182 matches
Mail list logo
