On Thu, Oct 29, 2015 at 8:18 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Sep 24, 2015 at 6:36 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Thu, Sep 24, 2015 at 6:32 PM, Andres Freund
>> wrote:
>>
>>&g
On Thu, Sep 24, 2015 at 6:36 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Sep 24, 2015 at 6:32 PM, Andres Freund wrote:
>
>> On 2015-09-15 20:16:10 +0300, YUriy Zhuravlev wrote:
>> > We will be tested.
>>
>> Did you have a chance to
onb.
> > > Maybe I should publish this code?
> >
> > Please do.
> Tom Lane and Robert Haas are very unhappy with a python. Is there any
> reason?
>
Requirement of python with pycparser as build dependency is a
serious cataclysm. For instance, how many buildfarms wil
On Fri, Oct 16, 2015 at 7:11 PM, Alexander Korotkov
wrote:
> On Sun, Jun 7, 2015 at 11:01 PM, Peter Geoghegan wrote:
>
>> On Sun, Jun 7, 2015 at 8:10 AM, Andreas Karlsson
>> wrote:
>> > Are you planning to work on this patch for 9.6?
>>
>> FWIW I hope s
h is attached. This
patch isn't passing regression tests because of plan changes. I'm not yet
sure about those changes: why they happens and are they really regression?
Since I'm not very familiar with planning of INSERT ON CONFLICT and RLS,
any help is appreciated.
--
m marking this patch as ready for committer. It would be cool in
> the future to use the recovery test suite to have more advanced
> scenarios tested, but it seems a shame to block this patch because of
> that.
>
Thanks a lot. Now patch looks much better.
I found that it doesn't a
orTimeline:
> if (ControlFile_target.checkPointCopy.ThisTimeLineID ==
> ControlFile_source.checkPointCopy.ThisTimeLineID)
> pg_fatal("source and target cluster are on the same
> timeline\n");
> Alexander, what do you think about that? I
ose macros.
>
In my opinion it would be cool remove FP macros. I see absolutely no sense
in them. But since it break compatibility it would be quite hard though.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
geometric
types.
In short: once we implement it for built-in geometric types, you can ask
PostGIS team to do the same for their geometry/geography.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ences only search and can't lead to
corrupt indexes. However, "same" method can lead to corrupt indexes.
However, this is not the reason to not backpatch the changes and preserve
buggy behaviour; this is the reason to recommend reindexing to users. And
it was already backpatched.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
non-empty array its boundaries isn't extending. If one update
non-empty array out of its boundaries then he get an error "ERROR: array
subscript out of range".
If we extrapolate this logic to empty arrays then we this error should be
thrown on any update of empty array. Despite this, we allow any update of
empty array.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
is, it would be a good thing if
> the documentation got a review from a native English speaker. I will
> volunteer to handle it if someone else does the first draft.
>
Great! I'll write this documentation.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Sep 24, 2015 at 6:32 PM, Andres Freund wrote:
> On 2015-09-15 20:16:10 +0300, YUriy Zhuravlev wrote:
> > We will be tested.
>
> Did you have a chance to run some benchmarks?
>
Yes, we now have 60 physical cores intel server and we're running
benchmarks on it.
--
On Thu, Sep 17, 2015 at 5:38 PM, Andres Freund wrote:
> On 2015-09-17 14:35:20 +0300, Alexander Korotkov wrote:
> > while exploring lwlock.c I found following macro to be strange.
> >
> > #define LW_SHARED_MASK ((uint32)(1 << 23))
> >
> > This is macro is
On Sun, Sep 20, 2015 at 5:18 PM, Tom Lane wrote:
> Petr Jelinek writes:
> > On 2015-09-18 14:58, Alexander Korotkov wrote:
> >> After, further personal discussion with Teodor, we decided that
> >> amvalidate is out of scope for this patch.
> >> It'
On Sun, Sep 20, 2015 at 5:02 PM, Petr Jelinek wrote:
> On 2015-09-18 14:58, Alexander Korotkov wrote:
>
>> On Wed, Sep 16, 2015 at 8:44 PM, Teodor Sigaev > <mailto:teo...@sigaev.ru>> wrote:
>>
>> validate_opclass was renamed to amvalidate.
>>
On Wed, Sep 16, 2015 at 7:47 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Sep 10, 2015 at 8:33 AM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> On Wed, Sep 9, 2015 at 7:13 PM, Alexander Korotkov wrote:
>
> &
swaiters %u waiters %u rOK %d",
MyProcPid,
where, MainLWLockNames[id],
!!(state & LW_VAL_EXCLUSIVE),
state & LW_SHARED_MASK,
!!(state & LW_FLAG_HAS_WAITERS),
pg_atomic_read_u32(&lock->nwaiters),
!!(state & LW_FLAG_RELEASE_OK;
Should it be ((uint32) ((1 << 24)-1))
rom slot 3.
>
Hmm, I think we should store cutoff_freq / nonnull_cnt as minfreq when we
collect no MCEs. Moreover, I think we should store it even when num_mcelem
>= track_len and we haven't cut MCEs we find. In this case we can get more
precise estimation for rare element using the
On Thu, Sep 10, 2015 at 8:33 AM, Michael Paquier
wrote:
> On Wed, Sep 9, 2015 at 7:13 PM, Alexander Korotkov wrote:
> > On Wed, Sep 9, 2015 at 9:01 AM, Michael Paquier wrote:
> >> The code building the target history file is a duplicate of what is done
> >> with t
On Mon, Sep 14, 2015 at 3:03 PM, Robert Haas wrote:
> On Mon, Sep 14, 2015 at 5:32 AM, Alexander Korotkov
> wrote:
> > In order to build the consensus we need the roadmap for waits monitoring.
> > Would single byte in PgBackendStatus be the only way for tracking wait
> &g
On Mon, Sep 14, 2015 at 2:12 PM, Amit Kapila
wrote:
> On Mon, Sep 14, 2015 at 2:25 PM, Alexander Korotkov
> wrote:
>
>> On Sat, Sep 12, 2015 at 2:05 PM, Amit Kapila
>> wrote:
>>
>>> On Thu, Aug 6, 2015 at 3:31 PM, Ildus Kurbangaliev <
>>> i.kurba
On Mon, Sep 14, 2015 at 2:25 PM, Amit Kapila
wrote:
> On Mon, Sep 14, 2015 at 3:02 PM, Alexander Korotkov
> wrote:
>
>> On Sat, Sep 12, 2015 at 3:24 PM, Amit Kapila
>> wrote:
>>
>>> On Fri, Aug 14, 2015 at 7:23 PM, Alexander Korotkov <
>>> aekoro
On Sat, Sep 12, 2015 at 3:24 PM, Amit Kapila
wrote:
> On Fri, Aug 14, 2015 at 7:23 PM, Alexander Korotkov
> wrote:
> >
> > On Thu, Aug 6, 2015 at 1:01 PM, Ildus Kurbangaliev <
> i.kurbangal...@postgrespro.ru> wrote:
> >>
> >>
> >> I&#x
backends information, it will not make sense to include
> information about backend processes in this variable as pg_stat_activity
> just displays information of backend processes.
>
I'm not objecting that we should track only backends information in
pg_stat_activity. I think we should have also some other way of tracking
wait events for background processes. We should think it out before
extending pg_stat_activity to evade design issues later.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
icantly simplified and improved on top of [1] and [2].
>
> Great - let's try to deal with [1] first, then.
>
> Does anyone wish to object to me committing that part?
>
No objections from me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Sep 9, 2015 at 9:01 AM, Michael Paquier
wrote:
>
>
> On Wed, Sep 9, 2015 at 3:27 AM, Alexander Korotkov
> wrote:
>
>> On Tue, Sep 8, 2015 at 10:28 AM, Michael Paquier
>> wrote:
>>
>>> I am planning to do as well a detailed code review rather
On Tue, Sep 8, 2015 at 10:28 AM, Michael Paquier
wrote:
> On Tue, Sep 8, 2015 at 1:14 AM, Alexander Korotkov wrote:
> > On Thu, Aug 20, 2015 at 9:57 AM, Michael Paquier wrote:
> >> The code above looks correct to me when scanning the WAL history onwards
> >> though,
On Mon, Sep 7, 2015 at 10:02 PM, Petr Jelinek wrote:
> On 2015-09-07 20:56, Alexander Korotkov wrote:
>
>> On Mon, Sep 7, 2015 at 9:17 PM, Petr Jelinek >
>> However I don't like the naming differences between validate_opclass
>> and amvalidate. If you ex
On Mon, Sep 7, 2015 at 9:17 PM, Petr Jelinek wrote:
> On 2015-09-04 16:26, Alexander Korotkov wrote:
>
>>
>> Attached patch is implementing this. It doesn't pretend to be fully
>> correct implementation, but it should be enough for proof the concept.
>>
On Thu, Aug 20, 2015 at 9:57 AM, Michael Paquier
wrote:
> On Wed, Jul 22, 2015 at 4:28 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Wed, Jul 22, 2015 at 8:48 AM, Michael Paquier <
>> michael.paqu...@gmail.com> wrote
>>
>>
der
GenericXLogRegister was called.
Patches was rebased against latest version of am interface rework patch.
http://www.postgresql.org/message-id/CAPpHfduGY=KZSBPZN5+USTXev-9M2PAUp3Yi=syfdo2n244...@mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian P
o this problem is good. It would be very nice if Simon or Andres
give review of this.
[4] -
http://www.postgresql.org/message-id/CAPpHfdtdF8LyR0zBA_tzAwYq00GFZyVbh_XfFAABRQQ=mbn...@mail.gmail.com
[5] - http://www.postgresql.org/message-id/55c3306b.5010...@postgrespro.ru
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
have posting tree, you have to do exclusive lock on one page of
posting tree.
One can say that concurrency would became worse because index would become
smaller and number of pages would became smaller too. Since number of pages
would be smaller, backends are more likely concur for the same page. But
this argument can be user against any compression and for any bloat.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
or abort using GenericXLogAbort(). In
the case of abort initial state of pages will be reverted.
Generic xlog takes care about critical section, unlogged relation, setting
lsn, making buffer dirty. User code is just simple and clear.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.
f
their CSN patch and further work in this direction together with community.
However, it's even not published yet despite all the promises. Nobody from
Huawei answers CSN thread in the hackers.
So, I think we got nothing from Huawei except teasing and should rely only
on ourselves. That is dis
On Mon, Aug 31, 2015 at 4:31 PM, Andres Freund wrote:
> On 2015-08-31 16:22:54 +0300, Alexander Korotkov wrote:
> > Is it correct to switch 2015-09 commitfest to inprogress now?
>
> Yea, isn't it only starting the 15th?
AFICS, on the last developer meeting it was decided
ect to switch 2015-09 commitfest to inprogress now?
I thought we should still accept patches to 2015-09 since it's 2015-08-31
now.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Aug 26, 2015 at 7:20 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane wrote:
>
>> Alexander Korotkov writes:
>> > OK. So, as we mentioned before, if we need to expose something of am
>> > parameter
On Wed, Aug 26, 2015 at 6:50 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > OK. So, as we mentioned before, if we need to expose something of am
> > parameters at SQL-level then we need to write special functions which
> would
> > call amhandler and expose it
> > with views.
>
> I've looked into having actual child tables in the system catalogs, and
> I'm afraid that the pain-to-reward ratio doesn't look very good.
>
Agree. Teach syscache about inheritance would be overengeneering for this
problem.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Aug 24, 2015 at 5:15 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Aug 10, 2015 at 7:50 PM, Tom Lane wrote:
> >> Hm. So one way or the other we're going to end up violating relational
> >> theory somewhere. OK, I yield: let
te data structure with different
> concurrency model which would be most suitable for monitoring.
+1 for tracking wait events not only for backends
Ildus, could you do following?
1) Extract LWLocks refactoring into separate patch.
2) Make a patch with storing current wait event information in PGPROC.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane wrote:
> Petr Jelinek writes:
> > On 2015-08-10 16:58, Alexander Korotkov wrote:
> >> That should work, thanks! Also we can have SQL-visible functions to get
> >> amsupport and amstrategies and use them in the regressi
On Mon, Aug 10, 2015 at 6:36 PM, Petr Jelinek wrote:
> On 2015-08-10 16:58, Alexander Korotkov wrote:
>
>> That should work, thanks! Also we can have SQL-visible functions to get
>> amsupport and amstrategies and use them in the regression tests.
>>
>>
> SQL-visi
On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek
> wrote:
> >> I don't understand this, there is already AmRoutine in RelationData, why
> >> the need for additional field for just
On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek wrote:
> On 2015-08-09 23:56, Alexander Korotkov wrote:
>
>> Hacker,
>>
>> some time before I proposed patches implementing CREATE ACCESS METHOD.
>>
>> http://www.postgresql.org/message-id/capphfdsxwzm
hed,
>
Thank you for notice and for the patch!
You should have maintenance_work_mem > 1gb and some very frequent entry so
that it's posting list exceeds 1 gb itself.
These circumstances shouldn't be very rare in modern systems. I think it
could be backpatched.
--
Alexander Korotk
> 3) fixed
>
Good! Another couple of notes from me:
1) I think gistvacuumpage() and gistkillitems() need function-level
comments.
2) ItemIdIsDead() can be used in index scan like it's done
in _bt_checkkeys().
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
to existing
tuples. Then we can use two format from listed above: #1 and #2, and take
one free bit from t_infomask2 for format indication.
Probably I'm missing something, but I think keeping on-disk compatibility
should be somehow possible.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
27;t be used by new tuples since the
> system is now in different epoch.
It is not so easy to move heap tuple to the different page. When table has
indexes each tuple is referenced by index tuples as (blockNumber; offset).
And we can't remove these references without vacuum. Thus, we woul
On Thu, Jul 30, 2015 at 5:24 PM, Heikki Linnakangas wrote:
> On 07/30/2015 04:26 PM, Alexander Korotkov wrote:
>
>> Also, I think it's possible to migrate to 64-bit XIDs without breaking
>> pg_upgrade. Old tuples can be leaved with 32-bit XIDs while new tuples
>>
-bit XIDs while new tuples
would be created with 64-bit XIDs. We can use free bits in t_infomask2 to
distinguish old and new formats.
Any thoughts? Do you think 64-bit XIDs worth it?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
re spaces
and open brace should be on the next line.
+ if ((scan->kill_prior_tuple)&&(so->curPageData > 0)&&(so->curPageData ==
so->nPageData)) {
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
different option for optimizing this. When we set
hint bits we can also change XMIN/XMAX with CSN. In this case we wouldn't
need to do XID => CSN transformation for this tuple anymore. However, we
have 32-bit XIDs for now. We could also have 32-bit CSNs. However, that
would doubles our troubles with wraparound: we will have 2 counters that
could wraparound. That could return us to thoughts about 64-bit XIDs.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
pen
source.
http://www.pgcon.org/2015/schedule/events/810.en.html
However, it isn't published yet, and we don't know how long we could wait
for it.
Now, our company have resources to work on CSN based snapshots for 9.6. If
Huawei will not publish their patch, we can pick up this work from last
community version of this patch.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Jul 22, 2015 at 8:48 AM, Michael Paquier
wrote:
> On Mon, Jul 20, 2015 at 9:18 PM, Alexander Korotkov
> wrote:
> > attached patch allows pg_rewind to work when target timeline was
> switched.
> > Actually, this patch fixes TODO from pg_rewind comments.
> >
On Tue, Jul 21, 2015 at 7:20 PM, Heikki Linnakangas wrote:
> On 07/21/2015 04:14 PM, Alexander Korotkov wrote:
>
>> On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas
>> wrote:
>>
>> On 07/21/2015 02:56 PM, Alexander Korotkov wrote:
>>>
>>> P
On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas wrote:
> On 07/21/2015 03:44 PM, Alexander Korotkov wrote:
>
>> While Uriy is on vacation, I've revised this patch a bit.
>>
>
> I whacked this around quite a bit, and I think it's in a committable state
&g
but
doesn't handle "const @@ var" and "var ~~ const". It determines the case
by type of variable: it should be int[].
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
intarray_sel-3.patch
Description: Binary data
On Tue, Jul 21, 2015 at 3:52 PM, Heikki Linnakangas wrote:
> On 07/21/2015 02:56 PM, Alexander Korotkov wrote:
>
>> Probably, but currently we are in quite unlogical situation. We have
>> default fillfactor = 90 for GiST where it has no use cases at all and
>> effect
dn't do it for any selectivity estimation functions yet.
Problem is that selectivity estimation is quite complex process and its
result depending on random sampling during analyze, floating points
operations and so on. We could make a test like "with very high level of
con
ite unlogical situation. We have
default fillfactor = 90 for GiST where it has no use cases at all and
effectively is just a waste of space. On the other had we're rejecting
fillfactor for GIN where it could have at least some use cases... Should we
don't have fillfactor for both GiST and GIN?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
index | smagen | foo | 1608 kB |
public | foo_val_idx_90 | index | smagen | foo | 1200 kB |
(2 rows)
Based on this, I think we should just drop this patch. It's not useful in
> practice.
I wouldn't say it's not useful at all. It's for sure not as useful as btree
fillfactor, but it still could be useful in some cases...
Probably, we could leave 100 as default fillfactor, but provide an option.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Jul 15, 2015 at 12:31 AM, Jeff Janes wrote:
> On Tue, Jul 7, 2015 at 6:33 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>>
>>
>> See Tom Lane's comment about downgrade scripts. I think just remove it is
>> a right solution.
>
in function interfaces instead of
specifying TLI directly. Thus, SimpleXLogPageRead() can easily start
reading XLOGs from next timeline when current timeline ends.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
eneral, there could be some systems where accurate measurements of time
intervals is impossible or slow. That means we should provide them some
different solution like sampling. But does it means we should force
majority of systems use sampling which is both slower and less accurate for
them? Could we
r instance, having
duration of current wait event, user can determine if backend is getting
stuck on particular event without sampling.
2) Accumulate per backend statistics about each wait event type: number of
occurrences and total duration. With this statistics user can identify
system bottl
On Fri, Jul 10, 2015 at 4:54 AM, Michael Paquier
wrote:
>
>
> On Thu, Jul 9, 2015 at 10:33 PM, Alexander Korotkov wrote:
> > [...]
>
> + /* Caclculate max data size on page according to fillfactor */
> s/Caclculate/Calculate
>
> When creating a simp
hould join work of Robert and Amit in inclusion current lock
type into PgBackendStatus. There are things you could help them to improve.
And then you can rebase waits monitoring patch according to it.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
patch. Did forget to include it?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
that maxdatasize becomes smaller than
> GinPostingListSegmentMaxSize, which is a problem. I think
> GinGetMaxDataSize() needs to make sure that the returned value is always >=
> GinPostingListSegmentMaxSize.
>
Fixed.
> Now that we have a fillfactor, shouldn't we replace the
xpected/select_views.out
Hunk #1 succeeded at 1411 (offset 46 lines).
Hunk #2 succeeded at 1432 (offset 46 lines).
Hunk #3 succeeded at 1466 (offset 46 lines).
Hunk #4 succeeded at 1497 (offset 46 lines).
patching file src/test/regress/expected/select_views_1.out
Hunk #1 succeeded at 1411 (offset 46
On Tue, Jun 30, 2015 at 11:28 PM, Jeff Janes wrote:
> On Tue, Jun 30, 2015 at 2:46 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Sun, Jun 28, 2015 at 1:17 AM, Jeff Janes wrote:
>>
>>> This patch implements version 1.2 of contrib modul
ies to 9.4 code with a minor conflict in the Makefile,
> and gives benefits there as well.
>
Some other notes about the patch:
* You allocate boolcheck array and don't use it.
* Check coding style and formatting, in particular "check[i]==GIN_TRUE"
should be "check[i] =
Josh,
On Tue, Jun 9, 2015 at 9:16 PM, Josh Berkus wrote:
> Dmitry, Alexander:
>
> I'm noticing a feature gap for JSONB operators; we have no way to do this:
>
> jsonb_col ? ARRAY['key1','key2','key3']
>
What documents do you expect to match
On Thu, May 28, 2015 at 6:43 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > Could we address both this problems by denying changing existing
> > commutators and negator? ISTM that setting absent commutator and negator
> is
> > quite enough for ALTER OPERATOR. Us
quite enough for ALTER OPERATOR. User extensions could need setting of
commutator and negator because they could add new operators which don't
exist before. But it's rather uncommon to unset or change commutator or
negator.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
empty
room and nobody there. Didn't try to visit it anytime after.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
e could include
into the patch documentation statement about possible side effects with
cached query plans.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, May 15, 2015 at 2:49 PM, Alexander Korotkov
wrote:
> On Fri, May 15, 2015 at 2:48 PM, Heikki Linnakangas
> wrote:
>
>> On 05/15/2015 11:31 AM, Alexander Korotkov wrote:
>>
>>> On Fri, May 15, 2015 at 2:30 AM, Heikki Linnakangas
>>> wrote:
On Fri, May 15, 2015 at 2:48 PM, Heikki Linnakangas wrote:
> On 05/15/2015 11:31 AM, Alexander Korotkov wrote:
>
>> On Fri, May 15, 2015 at 2:30 AM, Heikki Linnakangas
>> wrote:
>>
>> On 05/15/2015 02:28 AM, Heikki Linnakangas wrote:
>>>
>>> I
7;t
>> wake up to a red buildfarm.
>>
>
> Forgot to attach the latest patch, here you go.
Looks good for me.
--
With best regards,
Alexander Korotkov.
On Wed, May 13, 2015 at 10:17 PM, Alexander Korotkov
wrote:
> One quick comment:
>>
>> It would be good to avoid the extra comparisons of the distances, when
>> the index doesn't return any lossy items. As the patch stands, it adds one
>> extra copyDistances() cal
On Wed, May 13, 2015 at 10:16 PM, Heikki Linnakangas
wrote:
> On 04/17/2015 12:05 PM, Alexander Korotkov wrote:
>
>> On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov <
>> aekorot...@gmail.com>
>> wrote:
>>
>> Hi!
>>>
>>> O
gator of operator: extension could add commutators and
negators in further versions. Any thoughts?
--
With best regards,
Alexander Korotkov.
intarray-sel-1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On Wed, Feb 25, 2015 at 12:15 PM, Alexander Korotkov
wrote:
> Hi!
>
> On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote:
>
>> On 17.2.2015 14:21, Alexander Korotkov wrote:
>> > On Sun, Feb 15, 2015 at 2:08 PM, Al
so that extension with old definition could work with new
binary.
--
With best regards,
Alexander Korotkov.
mplementing index_getnext() for GIN looks step forward for me because it
allows "index only count" and potentially could be used for ordered output.
However, it's unclear for me if it's feasible to have #4? Could we return
TOP-N results and total count from single GIN index scan?
--
With best regards,
Alexander Korotkov.
VSearchPath },
{NULL},
};
We could possibly alleviate problem #1 by changing the behavior of guc.c
> so it doesn't report every single transition of flagged variables, but
> only (say) once just before ReadyForQuery if the variable changed in
> the just-finished command. That's not exactly a one-line fix though.
>
Probably for some variables this really make sense. Inside stored
procedures any of GUC_REPORT variables can be changed the same way as
search_path (thousands of times), but not all of these variables directly
relate to the application visible behaviour.
Regards,
Alexander Kukushkin
the heap (perhaps do some deletes and
vacuum).
Actually, this is narrowing benefit from GIN fillfactor. Probably, that
means that we should still have default value of 100. But I think GIN
fillfactor still might be useful.
--
With best regards,
Alexander Korotkov.
Hi!
On Tue, Feb 24, 2015 at 5:39 PM, Tomas Vondra
wrote:
> On 17.2.2015 14:21, Alexander Korotkov wrote:
> > On Sun, Feb 15, 2015 at 2:08 PM, Alexander Korotkov
> > mailto:aekorot...@gmail.com>> wrote:
> >
> > Revised patch with reordering in GiST is attached
&g
posals accepted.
--
With best regards,
Alexander Korotkov.
On Sun, Feb 15, 2015 at 2:08 PM, Alexander Korotkov
wrote:
> Following changes has been made in attached patch:
>
> * Get sort operators from pathkeys.
> * Recheck argument of distance function has been reverted.
>
Few comments were added and pairing heap comparison functi
if item a should be
checked first function should return 1. Current behavior doesn't lead to
incorrect query answers, but it could be slower than correct version.
--
With best regards,
Alexander Korotkov.
pairing_heap_cmp_fix.patch
Description: Binary data
--
Sent via pgsql-hackers maili
On Thu, Jan 8, 2015 at 1:12 AM, Alexander Korotkov
wrote:
> On Tue, Dec 16, 2014 at 4:37 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> Patch attached. It should be applied on top of my pairing heap patch at
>> http://www.postgresql.org/message-id/
or a mentor.
>
I'm ready to participate as mentor again!
--
With best regards,
Alexander Korotkov.
s.coord->-4 LIMIT 10;
>
I've checked the patch. The first notes are so:
1) Check coding style, in particular braces. Postgres coding style require
using it for multiline statements.
2) Update documentation according to new features.
--
With best regards,
Alexander Korotkov.
transaction.
If not, could pg_dump return some more friendly error before actually
trying to dump?
--
With best regards,
Alexander Korotkov.
On Mon, Jan 19, 2015 at 5:46 PM, Cédric Villemain
wrote:
> Le lundi 19 janvier 2015 08:24:08 Robert Haas a écrit :
>
> > On Sat, Jan 17, 2015 at 4:49 AM, Alexander Korotkov
>
> >
>
> > wrote:
>
> > > I already wrote quite detailed explanation of subje
401 - 500 of 1182 matches
Mail list logo
