gt; This about halved the runtime of the TAP test, and it changed the coverage
> footprint not at all according to lcov. (Said coverage is only marginally
> better than what we get without running the bloom TAP test, AFAICT.)
>
> It seems like some effort could be put into both shortening this test
> and improving the amount of code it exercises.
>
Thank you for committing patch which fixes tap test.
I'll try to improve coverage of this test and reduce its run time.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
case. Alternatively, distance
function is not what it meant to be.
It would be useful if you provide complete usage example of this extension:
from image to signature conversion to search queries.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
to address your
comments if I continue working on the planner part.
--
Alexander Kuzmenkov
Postgres Professional: 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.postgres
gt; $(prove_check)
> >
> > This works for me as I would expect it should.
>
> Looks good to me too.
OK, then so be it :)
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
wal-check-on-bloom-check-3.patch
Description:
ve seen the only difference: when
tap tests are enabled, this version of Makefile runs tap tests before
regression tests. While my version of Makefile runs tap tests after
regression tests. That seems like more desirable behavior for me. But it
would be sill nice to simplify Makefile.
--
1", but not ok for "git
apply".
Sorry for that. I resubmit both of them.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix-bloom-wal-check-2.patch
Description: Binary data
wal-check-on-bloom-check-2.patch
Description
t; it'd be a good idea to extend the explain analyze output to include that
> >> information.
>
> > I certainly agree.
>
> Doesn't the EXPLAIN (BUFFERS) output already address this?
>
In plain index scan EXPLAIN (ANALYZE, BUFFERS) doesn't distinguish buffers
acce
distance value. However, it would place some limitations. For
instance, you wouldn't be able to use different distance threshold in the
same query.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Nov 1, 2017 at 5:55 AM, Masahiko Sawada
wrote:
> On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov
> wrote:
> > On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada
> > wrote:
> >>
> >> On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas
> >>
On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote:
> On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov
> wrote:
> > However, from user prospective of view, current behavior of
> > hot_standby_feedback is just broken, because it both increases bloat and
> > doesn&#x
should look for another approach.
I can propose following alternative approach: teach read-only queries on
hot standby to tolerate concurrent relation truncation. Therefore, when
non-existent heap page is accessed on hot standby, we can know that it was
deleted by concurrent truncation and sho
On Sun, Oct 29, 2017 at 12:47 AM, Pavel Stehule
wrote:
> 2017-10-28 23:35 GMT+02:00 Alexander Korotkov :
>
>> On Sat, Oct 28, 2017 at 3:46 PM, Pavel Stehule
>> wrote:
>>
>>> 2017-09-22 21:31 GMT+02:00 Pavel Stehule :
>>>
>>>>
On Sun, Oct 29, 2017 at 1:30 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Oct 20, 2017 at 1:01 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
> I've reviewed code of ~> operator and its KNN-GiST support.
> Unfortunately, it ap
Hi,
I am attaching the updated patch, rebased to 820c03.
On 09.10.2017 13:47, Ashutosh Bapat wrote:
Hi Alexander,
Commit c7a9fa399 has added another test on mergeopfamilies. I think
your patch will need to take care of that test.
On Wed, Oct 4, 2017 at 6:38 PM, Alexander Kuzmenkov
wrote:
As
possible to implement a SP-GiST indexing scheme as a loadable
> module?
> >>
> >> If so, how?
> >> And is there an example I can base my implementation off of?
> >
> > Look on RUM access method ( https://github.com/postgrespro/rum ) we
> > develop
hat it's important to select root pivot value basing
on the whole dataset. However, for your metric/dataset/queries it might
appear to be different.
It also would be nice to someday improve SP-GiST to support some global
strategies on index creation. In particular, it would allow to resol
On Fri, Oct 20, 2017 at 1:01 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Oct 20, 2017 at 12:52 AM, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote:
>
>> I've noticed this suspicious behavior of "cube" data type with OR
ze of objects, then I prefer the sort by size desc every time. If I need
>> to find some object, then I can to use a searching in pager. So in my case,
>> this settings will be in psqlrc. In GoodData we used years own
>> customization - the order by size was hardcoded and nobody r
e possibility that they're handed a toast-compressed value. I have
> not checked whether that really matters for cube.)
>
As I can see, cube GiST code always uses DatumGetNDBOX() macro to transform
Datum to (NDBOX *).
#define DatumGetNDBOX(x) ((NDBOX *) PG_DETOAST_DATUM(x))
Thus, it s
On Tue, Oct 24, 2017 at 10:56 AM, Ivan Kartyshov wrote:
> Hello. I made some bugfixes and rewrite the patch.
>
> Simon Riggs писал 2017-09-05 14:44:
>
>> As Alexander says, simply skipping truncation if standby is busy isn't
>> a great plan.
>>
>> If w
"
>
> -
> /*
> * Maximum size of a NOTIFY payload, including terminating NULL. This
> * must be kept small enough so that a notification message fits on one
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
367 | (31018, 367),(30946, 333)
> 377 | (11399, 377),(11360, 294)
> (15 rows)
>
>
> Seems like a bug somewhere in gist_cube_ops, I guess?
>
+1,
that definitely looks like a bug. Thank you for reporting!
I'll take a look on it in couple days.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Sep 6, 2017 at 4:42 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> We're currently blocking writing queries on standby if even they are
> modifying contents of foreign tables. But do we have serious reasons for
> that?
> Keeping in the mind FDW-shar
(and document it),
but don't tolerate wrong features. For instance, we may have some pluggable
storage which doesn't support transactions at all (and that should be
documented for sure), but we shouldn't have pluggable storage which
transaction support is wrong.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
of indexes.
Wherein these new index entries may have either same or new TIDs.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
it wouldn't have significant performance benefit, then there is no
reason to do something further...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Oct 11, 2017 at 11:08 PM, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov
> wrote:
> > For me, it's crucial point that pluggable storages should be able to have
> > different MVCC implementation, and correspondingly have full control ov
On Mon, Oct 9, 2017 at 5:32 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > For me, it's crucial point that pluggable storages should be able to have
> > different MVCC implementation, and correspondingly have full control over
> > its interactions with indexes.
On Wed, Sep 27, 2017 at 7:51 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> I took a look on this patch. I've following notes for now.
>
> tuple_insert_hook tuple_insert; /* heap_insert */
>> tuple_update_hook tuple_update; /* heap_update */
>>
On Thu, Oct 5, 2017 at 9:48 PM, Shubham Barai
wrote:
> On 3 October 2017 at 00:32, Alexander Korotkov
> wrote:
>
>> On Mon, Oct 2, 2017 at 9:11 PM, Andrew Borodin
>> wrote:
>>
>>> On Mon, Oct 2, 2017 at 8:00 PM, Alexander Korotkov
>>> wrote:
>&
SIReadLock on tuple is necessary.
However, ISTM that we could place SIReadLock on tuple after Before Row
Trigger and only in the case when trigger has cancelled an update.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
190192
14110108106 105
--
Alexander Kuzmenkov
Postgres Professional: 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.or
As discussed earlier, I changed the way we work with mergeopfamilies. I
use the "is_equality" flag to indicate whether the clause is an equality
one, and fill mergeopfamilies for both equality and inequality operators.
The updated patch is attached (rebased to 20b6552242).
--
enerate_series(1,1) i) to 'script.sql'
\i script.sql
Then user u1 can login successfully.
$ psql temp -U u1
psql (11devel)
Type "help" for help.
u10000@temp=#
Thus, in this simple case database CONNECT privilege works with out-of-line
ACL for me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ectly. We
could try to re-implement similar functionality which fits pageinspect
approach better. In particular, we can implement some low-level functions
whose show detailed information at page level. And on top of them we can
implement analogues of gevel functions in SQL or PL/pgSQL. Is it feasible?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Oct 3, 2017 at 9:19 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > This topic was already discussed (at least one time) in 2011. See [1]
> for
> > details. I'd like to raise that again.
>
> I'm a bit worried about adding a toast table to pg_clas
egradation in this case. That's very significant
degradation, but I wouldn't day that "performance completely tank".
Any thoughts? Should we consider TOASTing ACL entries or should we give up
with this?
Links:
1. https://www.commandprompt.com/blog/grant_schema_usage_
to
On Tue, Oct 3, 2017 at 5:55 PM, Robert Haas wrote:
> On Mon, Oct 2, 2017 at 8:07 PM, Alexander Korotkov
> wrote:
> > +1,
> > I see 3 options there:
> > 1) Drop high-order bit, as you proposed.
> > 2) Allow negative queryIds.
> > 3) Implement unsigned 64-t
On Tue, Oct 3, 2017 at 2:52 PM, Robert Haas wrote:
> On Mon, Oct 2, 2017 at 12:37 PM, Alexander Korotkov
> wrote:
> > I've applied patch on top of c12d570f and rerun the same benchmarks.
> > CSV-file with results is attached. There is no dramatical changes.
> Ther
ds would look rather nonlogical.
#3 would be attaching hard and long-term problem by insufficient reason.
Thus, #1 looks like most harmless solution.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
I think ideally, cached plan should be automatically invalidated and stored
procedure should work without error.
Not really sure if it's feasible...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Oct 2, 2017 at 9:11 PM, Andrew Borodin
wrote:
> On Mon, Oct 2, 2017 at 8:00 PM, Alexander Korotkov
> wrote:
> > What happen if exactly this "continue" fires?
> >
> >> if (GistFollowRight(stack->page))
> >> {
> >> if (!
ql and .out) are essential parts of the
patch. I see no point in posting them separately. Please, incorporate
them into your patch.
Did you check this patch with manually created composite type (made by
CREATE TYPE typname AS ...)?
--
Alexander Korotkov
Postgres Professional: http://www.p
t doesn't seems that any
posting tree would be generated by the tests that you've provided, because
all the TIDs could fit the single posting list. Note, that you can get
some insight into GIN physical structure using pageinspect contrib.
--
Alexander Korotkov
Postgres Professional: h
u for your hard work as CFM! That's tedious and
> largely thankless work, but it's needed to keep things moving.
>
+1,
Thank you very much, Daniel! It was a pleasure working with you at
commitfest.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Oct 1, 2017 at 8:27 PM, chenhj wrote:
> On 2017-10-01 04:09:19,"Alexander Korotkov"
> wrote:
>
> On Sat, Sep 30, 2017 at 8:18 PM, chenhj wrote:
>
>> On 2017-09-30 02:17:54，"Alexander Korotkov" > > wrote:
>>
>>
>> Great.
Hi, Andrew!
On Mon, Oct 2, 2017 at 1:40 PM, Andrew Borodin
wrote:
> Thanks for looking into the patch!
>
> On Thu, Sep 28, 2017 at 3:59 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>>
>>
>> In gistdoinsert() you do CheckForSerializ
On Sat, Sep 16, 2017 at 2:46 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Sep 14, 2017 at 2:48 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Patch rebased to current master is attached. I'm going to improve my
>&g
page-level predicate locking should happen only when
fast update is off.
Also, despite general idea is described in README-SSI, in-code comments
would be useful.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Sep 30, 2017 at 8:18 PM, chenhj wrote:
> On 2017-09-30 02:17:54，"Alexander Korotkov"
> wrote:
>
>
> Great. Now code of this patch looks good for me.
> However, we forgot about documentation.
>
>
>>The result is equivalent to replaci
icing it. They might have inaccurate statistics of queries execution,
but they don't notice it because they have nothing to compare.
2) Ideally, we should fix potential problems before they materialize, not
only after users complaints.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, Sep 29, 2017 at 8:10 PM, chenhj wrote:
> On 2017-09-30 00:53:31，"chenhj" wrote:
>
> On 2017-09-29 19:29:40，"Alexander Korotkov"
> wrote:
>
> On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote:
>>
>>
>>
> OK. That makes sense.
lumn GIN.
I mean that multicolumn GIN was a good solution of particular problem from
practical side of view. It allowed to implement very efficient algorithms
with minimal changes in planner/executor infrastructure. However,
multicolumn GIN doesn't look like a good design pattern we would
s need to escalate that would prevent that from working.
+1,
Very nice idea! Locking hash values directly seems to be superior over
locking hash index pages.
Shubham, do you have any comment on this?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Sep 6, 2017 at 5:06 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> I just realized that these lines of contrib/bloom/t/001_wal.pl don't
>> c
On Fri, Sep 29, 2017 at 10:07 AM, chenhj wrote:
> On 2017-09-29 05:31:51, "Alexander Korotkov"
> wrote:
>
> On Thu, Sep 28, 2017 at 10:52 PM, chenhj wrote:
>
>> On 2017-09-29 00:43:18，"Alexander Korotkov"
>> wrote:
>>
>> On Thu, Sep
On Thu, Sep 28, 2017 at 2:22 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai
> wrote:
>
>> I am attaching a patch for predicate locking in SP-Gist index
>>
>
> I took a look over this patch.
>
>
On Thu, Sep 28, 2017 at 10:52 PM, chenhj wrote:
> On 2017-09-29 00:43:18，"Alexander Korotkov"
> wrote:
>
> On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote:
>
>> On 2017-09-28 01:29:29，"Alexander Korotkov"
>> wrote:
>>
>> It appears
On Thu, Sep 28, 2017 at 6:44 PM, chenhj wrote:
> On 2017-09-28 01:29:29，"Alexander Korotkov"
> wrote:
>
> It appears that your patch conflicts with fc49e24f. Please, rebase it.
>
>
> Yes, i had rebased it, Please check the new patch.
>
Good, now it appli
opfamilies.
The current commitfest is ending, but I'd like to continue working on
this patch, so I am moving it to the next one.
[1]
https://www.postgresql.org/message-id/flat/CAMp0ubfwAFFW3O_NgKqpRPmm56M4weTEXjprb2gP_NrDaEC4Eg%40mail.gmail.com#camp0ubfwaffw3o_ngkqprpmm56m4wetexjpr
her busy page
during split (see other branches in doPickSplit()). Your patch doesn't
seem to handle this case correctly.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
SerializableConflictIn(r, NULL, stack->buffer);
> xlocked = true;
However, page might be exclusively locked before. And in this case
CheckForSerializableConflictIn() would be skipped. That happens very
rarely (someone fixes incomplete split before we did), but nevertheless.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Sep 28, 2017 at 12:45 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, Aug 9, 2017 at 6:30 PM, Shubham Barai
> wrote:
>
>> Please find the updated patch for predicate locking in gin index here.
>>
>> There was a small issue in the prev
ree leaf page. So, there is no
necessity to lock posting tree leaf pages at all. Alternatively, if entry
has posting tree, you can skip locking entry tree leaf page and lock
posting tree leaf pages instead.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Sep 25, 2017 at 6:26 PM, chenhj wrote:
> On 2017-09-23 01:59:0, "Alexander Korotkov"
> wrote:
>
> On Fri, Sep 22, 2017 at 7:16 PM, chenhj wrote:
>
>> This is the new pacth with TAP test and use Macro XLOGDIR.
>>
>
> Good. I took a q
from rewrite_heap_tuple(). That
makes me think that tuple_freeze API method is wrong for abstraction. We
probably should make rewrite_heap_tuple() or even the
whole rebuild_relation() an API method...
Heap reloptions are untouched for now. Storage AM should be able to
provide its own specific
an_getnext_function to be about getting the next function...
>>
>
> OK. How about adding _hook?
>
I've answered to Andrew why I think _function suffix is OK for now.
And I don't particularly like _hook suffix for this purpose, because those
functions are parts of API implem
fix looks long for me too. But we should look on this
question from uniformity point of view.
FdwRoutine, TsmRoutine, IndexAmRoutine use _function suffix. This is why I
think we should use _function suffix for StorageAmRoutine unless we're
going to change that for other *Routines too.
--
owing syntax options.
WAITLSN lsn;
WAITLSN lsn TIMEOUT delay;
WAITLSN lsn INFINITE;
WAITLSN lsn NOWAIT;
For me that looks rather better. What do you think?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ode_slave->safe_psql()
instead.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Sep 21, 2017 at 12:08 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Sep 18, 2017 at 12:41 PM, Daniel Gustafsson
> wrote:
>
>> > On 16 Sep 2017, at 01:51, Alexander Korotkov
>> wrote:
>> >
>> > On Tue, Sep 5,
On Mon, Sep 18, 2017 at 12:41 PM, Daniel Gustafsson wrote:
> > On 16 Sep 2017, at 01:51, Alexander Korotkov
> wrote:
> >
> > On Tue, Sep 5, 2017 at 2:47 PM, Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
> > > On 04 Apr 2017, at 14:58, Da
On Thu, Sep 21, 2017 at 3:14 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski <
> >> It seems to me that any circle with radius of any Infinity should
> become a
> >> [-Infinity .. In
bles for "non
verbose" mode of commands too.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
to output of \dt+ commands
> > - there result is platform depend.
>
> How so?
\dt+ reports relation sizes whose are platform depended.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ounded for
any query, saying: "index can't help you for this kind value, only recheck
can deal with that". Therefore, we would at least guarantee that results
of sequential scan and index scan are the same.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
of those patches would be particularly large, and since they'd need
> to touch adjacent code in some places, the diffs wouldn't be independent.
> I think splitting them is just make-work.
>
I've extracted polygon opclass into separate patch (attached). I'll rework
and resu
w exact calculations and take less space.
> How about removing circle from the scope of this patch, so it is smaller
> and cleaner?
Good point. Polygons are enough for compress function example. Opclass
for circles could be submitted as separate patch.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Sep 20, 2017 at 5:02 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Wed, Sep 20, 2017 at 4:25 PM, Tom Lane wrote:
> >> Yes. We don't allow out-of-line values, but we do allow compressed and
> >> short-header values.
>
> > BTW
ethod with detoasting
or detoast every input key in all other methods.
BTW, this comment looks still invalid for me...
> #define SIGLENINT 4 /* >122 => key will *toast*, so very slow!!! */
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Sep 18, 2017 at 6:21 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Aug 25, 2015 at 4:05 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> On Thu, Jul 23, 2015 at 6:18 PM, Teodor Sigaev wrote:
>> >>> Poorly
you point where to look at the code or who to ask:
> Can there be TOASTed values in index tuples?
>
> If answer is NO, we can get rid of much more useless code.
>
And get rid of misleading comments too. For instance, this comment in
hstore_gist.c seems misleading for me.
#define SI
ere.
GBT_VARKEY *key = (GBT_VARKEY *) PG_DETOAST_DATUM(entry->key);
> if (key != (GBT_VARKEY *) DatumGetPointer(entry->key))
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Sep 19, 2017 at 7:54 PM, Pavel Stehule
wrote:
> 2017-09-19 16:14 GMT+02:00 Alexander Korotkov :
>
>> On Fri, Sep 8, 2017 at 7:13 AM, Pavel Stehule
>> wrote:
>>
>>> 2017-08-16 14:06 GMT+02:00 Pavel Stehule :
>>>
>>>> H
egression tests.
However, patch misses regression tests covering added functionality.
Patch is definitely harmless, i.e. it doesn't affect anybody who doesn't
use new functionality.
But I still would prefer ordering to be options of \d* commands while psql
variables be defaults for those options...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks good to me.
The new status of this patch is: Ready for
to
pickup this patch.
AFAICS, the progress on this patch was suspended because we have no example
for SP-GiST compress method in core/contrib.
However, now we have acdf2a8b committed with 2d to 4d indexing of boxes
using SP-GiST. So, extending this 2d to 4d approach to polygons would be
good exa
JSON path with
> explicitly
> specified types is rather interesting, and I think it should be shown now
> to get a some kind of pre-review.
>
> We are supporting v11 and v10 branches in our github repository:
>
> https://github.com/postgrespro/sqljson/tree/sqljson
> https://github.com/postgrespro/sqljson/tree/sqljson_wip
> https://github.com/postgrespro/sqljson/tree/sqljson_v10
> https://github.com/postgrespro/sqljson/tree/sqljson_v10_wip
>
>
> We provide web interface to our build
> http://sqlfiddle.postgrespro.ru/#!21/
>
+1,
For experimenting with SQL/JSON select "PostgreSQL 10dev+SQL/JSON" in the
version select field on top toolbar.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
red by tap tests. In particular,
new tests may generate more WAL files and make sure that pg_rewind fetches
only required files among them.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Sep 5, 2017 at 2:47 PM, Daniel Gustafsson wrote:
> > On 04 Apr 2017, at 14:58, David Steele wrote:
> >
> > On 4/4/17 8:55 AM, Alexander Korotkov wrote:
> >> On Mon, Apr 3, 2017 at 9:58 PM, Andres Freund >>
> >>I'm inclined to push t
On Fri, Sep 15, 2017 at 3:36 PM, Andrey Borodin
wrote:
> > 14 сент. 2017 г., в 18:42, Alexander Korotkov
> написал(а):
> > It would be good if someone would write patch for removing useless
> compress/decompress methods from builtin and contrib GiST opclasses.
> Especially
gger.sql
Do I understand correctly that this is SQL implementation of COMMIT TRIGGER
functionality which is a prototype used to demonstrate it. And if this
prototype is well-accepted then you're going to write a patch for builtin
COMMIT TRIGGER functionality. Is it right?
--
Alexand
completely. So what you're doing now is probably acceptable.
+1,
FDW looks OK for prototyping pluggable storage, but it doesn't seem
suitable for permanent implementation.
BTW, Hadi, could you visit "Pluggable storage" thread and check how
suitable upcoming pluggable stora
at tablesample methods are already
pluggable, making them storage-AM-specific would lead to user-visible
changes. I.e. tablesample method should be created for particular storage
AM or set of storage AMs. However, I didn't yet figure out what should API
exactly look like...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
GiST opclasses.
Especially when it gives benefit in IndexOnlyScan enabling.
BTW, this change in the patch look suspicious for me.
> @@ -913,7 +931,6 @@ gistproperty(Oid index_oid, int attno,
> ReleaseSysCache(tuple);
>
> /* Now look up the opclass family and input datatype. */
>
Thanks Rafia, Amit, now I understand the ideas behind the patch better.
I'll see if I can look at the new one.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
see any point in leaving DirectWalk and InvertedWalk in RB-tree.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ten with
atomics. I think it would be great to try this approach because it
doesn't add much code, doesn't add any additional copying and improves
shm_mq performance in general.
--
Alexander Kuzmenkov
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
--
On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> I just realized that these lines of contrib/bloom/t/001_wal.pl don't
> check that queries give same results on master and standby. They just
> check that *return codes* of psql are e
imple patch enabling writing to foreign tables from standbys. It
works from the first glance for me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
standby-fdw-writable.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (
1 - 100 of 1182 matches
Mail list logo
