The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
The patch looks fine to me. Changes are clear and all functions are
code don't needed anymore and can be deleted. Thank you for the
notice. I will send updated patch today.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
31.03.2017 20:57, Robert Haas:
On Fri, Mar 31, 2017 at 1:40 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
First of all, I want to thank you and Robert for reviewing this patch.
Your expertise in postgres subsystems is really necessary for features like
this.
I just wonde
lls.
But index_form_tuple_extended() looks like a better solution.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
tive comment.
+* NOTE It is not crutial for reliability in present,
Spelling, punctuation.
Will be fixed as well.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi, I've tried to review this patch, but it seems that I miss something
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch looks good to me.
It applies clearly, passes all the
Patch rebased to the current master is in attachments.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
commit 497d52b713dd8f926b465ddf22f21db7229b12e3
Author: Anastasia <a.lubennik...@postgrespro.ru>
Date: Tue Mar 21 12:58:13 2017
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
As I can see, this bugfix was already discussed and reviewed.
ut"
"/home/anastasia/newprojects/original_repo/postgres/contrib/btree_gin/results/enum.out"
>
"/home/anastasia/newprojects/original_repo/postgres/contrib/btree_gin/results/enum.out.diff"
Please, add regression test for btree_gin, and this patch can be
considere
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
As I see, this bugfix works as expected and the patch is
As far as I understand, in this thread were discussed two bugs of
pg_stop_backup().
Thanks to the clear descriptions above, I easily reproduced both of them.
BUG#1:
Server crashes on assertion on call of pg_stop_backup(false) after interrupted
call of pg_stop_backup(false).
TRAP:
13.03.2017 11:53, Artur Zakirov:
On 15.02.2017 20:54, Anastasia Lubennikova wrote:
Done.
I have gotten the error that AlterUserMappingStmt doesn't have
if_not_exists (in Russian):
gram.y: В функции «base_yyparse»:
gram.y:4918:7: ошибка: «AlterUserMappingStmt {aka struct
13.02.2017 19:34, Andrew Dunstan:
On 01/13/2017 08:36 AM, Anastasia Lubennikova wrote:
I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER
MAPPING statements
for one of our customers.
I think other users can also find it useful for scripting and
automated tasks.
The patches
add support of json and other types,
such as smallint and bigint.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/utils/adt/jsonb.c b/src/backend/utils/adt/jsonb.c
index b9bf18f..4bbe81c 100644
--- a/src/backend
for the patch. Hope to see it in 10.0.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
27.12.2016 17:33, Amit Kapila:
On Fri, Dec 23, 2016 at 6:42 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
22.12.2016 07:19, Amit Kapila:
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
<lubennikov...@gmail.com> wrote:
The following review has been po
I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER
MAPPING statements
for one of our customers.
I think other users can also find it useful for scripting and automated
tasks.
The patches themselves are small and simple. Documentation is updated as
well.
--
Anastasia
27.12.2016 20:14, Claudio Freire:
On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x006941e7 in lazy_vacuum_heap (onerel=0x1ec2360,
vacrelstats=0x1ef6e00) at vacuumlazy.
27.12.2016 16:54, Alvaro Herrera:
Anastasia Lubennikova wrote:
I ran configure using following set of flags:
./configure --enable-tap-tests --enable-cassert --enable-debug
--enable-depend CFLAGS="-O0 -g3 -fno-omit-frame-pointer"
And then ran make check. Here is the stacktrace
23.12.2016 22:54, Claudio Freire:
On Fri, Dec 23, 2016 at 1:39 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
I found the reason. I configure postgres with CFLAGS="-O0" and it causes
Segfault on initdb.
It works fine and passes tests with default configur
22.12.2016 21:18, Claudio Freire:
On Thu, Dec 22, 2016 at 12:22 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
On Thu, Dec 22, 2016 at 12:15 PM, Anastasia Lubennikova
<lubennikov...@gmail.com> wrote:
The following review has been posted through the commitfest application:
make
22.12.2016 07:19, Amit Kapila:
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
<lubennikov...@gmail.com> wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec com
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
I haven't read through the thread yet, just tried to apply the patch
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
Hi, thank you for the patch.
Results are very promising. Do
a PG_CONTROL_VERSION bump.
But as far as I see, we never use this data.
Could you please explain, why don't we use information from control file
in StartapXlog()?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers
utlook.com
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Could you please add the patches to commitfest?
I'm going to test them and write a review in a few days.
--
Anastasia Lubennikova
Postgres Professional: http://www.p
03.10.2016 15:29, Anastasia Lubennikova:
03.10.2016 05:22, Michael Paquier:
On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
Ok, I'll write it in a few days.
Marked as returned with feedback per last emails exchanged.
The only complaint
03.10.2016 05:22, Michael Paquier:
On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
Ok, I'll write it in a few days.
Marked as returned with feedback per last emails exchanged.
The only complaint about this patch was a lack of README,
, I have the same question.
I was confused, why do we always dump sequence data,
because I'd overlooked the --sequence-data key. I'd rather leave this
option,
because it's quite non intuitive behaviour...
/* dump sequence data even in schema-only mode */
--
Anastasia Lubennikova
Postgres
24.09.2016 15:36, Amit Kapila:
On Wed, Sep 21, 2016 at 6:51 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
20.09.2016 08:21, Amit Kapila:
On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
28.08.2016 09:13, Amit Kapila:
important or it is simply a legasy/overlooked code?
What do you think about moving stuff from pg_upgrade/file.c to storage/file/
to allow reuse of this code? I think it'll be really helpful for
developers of contrib modules
like backup managers.
--
Anastasia Lubennikova
Postgres Professional:http
15.09.2016 15:29, Peter Eisentraut:
On 9/14/16 8:52 AM, Anastasia Lubennikova wrote:
Could you clarify, please, why do we dump sequence in schemaOnly mode?
+ if (dopt.schemaOnly && dopt.sequence_data)
+ getSequenceData(, tblinfo, numTables, dopt.oids);
T
One more update.
I added ORDER BY clause to regression tests.
It was done as a separate bugfix patch by Tom Lane some time ago,
but it definitely should be included into the patch.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff
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, failed
Thank you for the patch.
As I see there are no objections in
28.08.2016 09:13, Amit Kapila:
On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
@@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState
*state, IndexTuple itup)
if (last_off == P_HIKEY)
{
Assert(state->btps_minke
06.09.2016 07:44, Pavan Deolasee:
On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru <mailto:a.lubennik...@postgrespro.ru>>
wrote:
Thank you for the review, I'll fix these problems in final version.
Posting the first message I inten
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
I haven't tested the performance yet, but the patch itself looks
haven't fully figured them out yet.
Thank you again for beginning the big project.
Looking forward to the prototype. I think it will make the discussion
more concrete and useful.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent v
09.08.2016 19:45, Andrew Borodin:
Here is new version of the patch, now it includes recommendations from
Anastasia Lubennikova.
I've investigated anamalous index size decrease. Most probable version
appeared to be true.
Cube extension, as some others, use Guttman's polynomial time split
robably because I haven't fully figured them out yet.
--
Anastasia Lubennikova
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.org/mailpref/pgsql-hackers
08.08.2016 12:43, Anastasia Lubennikova:
08.08.2016 03:51, Michael Paquier:
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera
<alvhe...@2ndquadrant.com> wrote:
Anastasia Lubennikova wrote:
So there is a couple of patches. They do not cover all mentioned
problems,
but I'd like to get a fe
ngs useful and important feature. Build shall be repaired; other
my suggestions are only suggestions.
Best regards, Andrey Borodin, Octonica & Ural Federal University.
The new status of this patch is: Waiting on Author
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.c
06.08.2016 19:51, Andrew Borodin:
Anastasia , thank you for your attentive code examine.
2016-08-05 21:19 GMT+05:00 Anastasia Lubennikova <a.lubennik...@postgrespro.ru>:
First of all, shouldn't we use MAXALIGN(oldsize) instead of oldsize?
Although, I'm quite sure that it was already a
08.08.2016 03:51, Michael Paquier:
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
Anastasia Lubennikova wrote:
So there is a couple of patches. They do not cover all mentioned problems,
but I'd like to get a feedback before continuing.
I agree that we
05.08.2016 20:56, Alvaro Herrera:
Anastasia Lubennikova wrote:
Working on page compression and some other issues related to
access methods, I found out that the code related to heap
looks too complicated. Much more complicated, than it should be.
Since I anyway got into this area, I want
.
You can find it on commitfest:
https://commitfest.postgresql.org/10/700/
I'll be glad to see your thoughts on the thread.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
duced significantly. 89MB against 289MB without patch.
Could you explain in details, why does it happen?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
05.08.2016 16:30, Kevin Grittner:
On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
They can be logically separated into three categories:
"primary storage" - r, S, t, v. They store data and visibility information.
The only implementa
t renaming and rearrangement of functions
between files, so, if nobody has conceptual objections, all I need from
reviewers
is an attentive look to find typos, grammar mistakes and overlooked areas.
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres
hould be memory safe.
That is not the project policy.
regards, tom lane
--
Dirk Rudolph | Senior Software Engineer
Netcentric AG
M: +41 79 642 37 11
D: +49 174 966 84 34
dirk.rudo...@netcentric.biz <mailto:dirk.rudo...@netcentric.biz> |
www.netc
c, argv);/* does not return */
#endif
And the last, but not least. Do we have any
presentations/articles/READMEs/whatever
about caches (src/backend/utils/cache/*) in postgresql?
I found nothing, besides comments in the code.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.c
orward
to see them.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 9c8e308..891325d 100644
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -100,7 +100,7 @@
08.04.2016 15:45, Anastasia Lubennikova:
08.04.2016 15:06, Teodor Sigaev:
On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan <p...@heroku.com> wrote:
Personally, I like documenting assertions, and will sometimes write
assertions that the compiler could easily optimize away. Maybe going
*tha
ut it's compatibility with
covering indexes.
We already discussed it in the thread
https://commitfest.postgresql.org/9/433/
Tiny attached patch fixes this issue.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/amcheck/amch
But now they are definitely unnecessary. Updated patch is attached
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 9c8e308..891325d 100644
--- a/contrib/dblink/dblink.c
+++ b/contr
our reply.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 9c8e308..891325d 100644
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -100,7 +100,7 @@ static r
06.04.2016 16:15, Anastasia Lubennikova :
06.04.2016 03:05, Peter Geoghegan:
* There is some stray whitespace within RelationGetIndexAttrBitmap().
I think you should have updated it with code, though. I don't think
it's necessary for HOT updates to work, but I think it could be
necessary so
ndex->nkeycolumns replacement in
match_clause_to_index. Fixed.
I also updated couple of typos in documentation.
Thank you again for the detailed review.
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/dblink/dblink.c
05.04.2016 01:48, Peter Geoghegan :
On Mon, Mar 21, 2016 at 9:53 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
It's a bit more complicated to add it into index creation algorithm.
There's a trick with a "high key".
/*
* We copy the last
17.03.2016 06:27, Vitaly Burovoy:
On 2016-03-15, David Steele <da...@pgmasters.net> wrote:
On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
On 3/4/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote:
I think that you should update documentation. At least description of
epoch
ession, I'll be glad to discuss them.
Same for any other ideas of B-tree optimization.
--
Anastasia Lubennikova
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 sub
21.03.2016 19:53, Anastasia Lubennikova:
19.03.2016 08:00, Peter Geoghegan:
On Fri, Mar 18, 2016 at 5:15 AM, David Steele <da...@pgmasters.net>
wrote:
It looks like this patch should be marked "needs review" and I have
done so.
Uh, no it shouldn't. I've posted an
ture works on suffix
truncation or something like that, but IMHO for now it's enough.
Do you have any objections or comments?
[1] https://commitfest.postgresql.org/9/494/
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/
, that allows to enable/disable compression
for each particular index.
4. Recheck locking considerations. I tried to write code as less
invasive as possible, but we need to make sure that algorithm is still
correct.
5. Change BTMaxItemSize
6. Bring back microvacuum functionality.
--
Anastasia
15.03.2016 22:28, David Steele:
On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
On 3/4/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote:
I think that you should update documentation. At least description of
epoch on this page:
http://www.postgresql.org/docs/devel/static/fun
14.03.2016 16:02, David Steele:
Hi Anastasia,
On 2/18/16 12:29 PM, Anastasia Lubennikova wrote:
18.02.2016 20:18, Anastasia Lubennikova:
04.02.2016 20:16, Peter Geoghegan:
On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
I fixed it in t
15.03.2016 03:21, Vitaly Burovoy:
On 3/14/16, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote:
14.03.2016 16:23, David Steele:
On 2/25/16 4:44 PM, Vitaly Burovoy wrote:
Added to the commitfest 2016-03.
[CF] https://commitfest.postgresql.org/9/540/
This looks like a
it as is?
But I suppose that behavior of undocumented dates is not essential.
--
Anastasia Lubennikova
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
02.03.2016 08:50, Michael Paquier:
On Wed, Mar 2, 2016 at 2:10 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
01.03.2016 19:55, Anastasia Lubennikova:
It is not the final version, because it breaks pg_dump for previous
versions. I need some help from hackers here.
pgdump
select bt_index_check('idx');
ERROR: cannot check index "idx"
DETAIL: index is not yet ready for insertions
But I'm sure that it's a problem of my patch. So I'll fix it and try again.
[1] https://commitfest.postgresql.org/9/433/
[2] https://commitfest.postgresql.org/9/494/
--
Anastasia L
* interesting.
Maybe you can expand it?
- Is JULIAN_MAXYEAR4STAMPS helps to avoid overflow in all possible cases?
- Why do we need to hold both definitions? I suppose, it's a matter of
backward compatibility, isn't it?
3. (nitpicking) I don't sure about "4STAMPS" suffix. "4&
29.02.2016 18:17, Anastasia Lubennikova:
25.02.2016 21:39, Jeff Janes:
As promised, here's the new version of the patch
"including_columns_4.0".
I fixed all issues except some points mentioned below.
Thanks for the update patch. I get a compiler warning:
genam.c: I
does not handle included columns
now. I will fix it in the next version of the patch.
--
Anastasia Lubennikova
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 subscrip
18.02.2016 20:18, Anastasia Lubennikova:
04.02.2016 20:16, Peter Geoghegan:
On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
I fixed it in the new version (attached).
Thank you for the review.
At last, there is a new patch version 3.0. Afte
02.02.2016 15:50, Anastasia Lubennikova:
31.01.2016 11:04, David Rowley:
On 27 January 2016 at 03:35, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
including_columns_3.0 is the latest version of patch.
And changes regarding the previous version are attached in a
separate
y related changes, please, let me know.
1.
http://www.postgresql.org/message-id/flat/56168952.4010...@postgrespro.ru#56168952.4010...@postgrespro.ru
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
29.01.2016 20:43, Thom Brown:
On 29 January 2016 at 16:50, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
29.01.2016 19:01, Thom Brown:
On 29 January 2016 at 15:47, Aleksander Alekseev
<a.aleks...@postgrespro.ru> wrote:
I tested this patch on x64 and ARM serve
31.01.2016 11:04, David Rowley:
On 27 January 2016 at 03:35, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
including_columns_3.0 is the latest version of patch.
And changes regarding the previous version are attached in a separate patch.
Just to ease the review and debu
28.01.2016 20:03, Thom Brown:
On 28 January 2016 at 16:12, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru <mailto:a.lubennik...@postgrespro.ru>>
wrote:
28.01.2016 18:12, Thom Brown:
On 28 January 2016 at 14:06, Anastasia Lubennikova
<a.lubennik...
roduce it, but I couldn't. Debug will be much easier now.
I hope I'll fix these issueswithin the next few days.
BTW, I found a dummy mistake, the previous patch contains some unrelated
changes. I fixed it in the new version (attached).
--
Anastasia Lubennikova
Postgres Professional: http://www
28.01.2016 18:12, Thom Brown:
On 28 January 2016 at 14:06, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru <mailto:a.lubennik...@postgrespro.ru>>
wrote:
31.08.2015 10:41, Anastasia Lubennikova:
Hi, hackers!
I'm going to begin work on effective storage of du
31.08.2015 10:41, Anastasia Lubennikova:
Hi, hackers!
I'm going to begin work on effective storage of duplicate keys in
B-tree index.
The main idea is to implement posting lists and posting trees for
B-tree index pages as it's already done for GIN.
In a nutshell, effective storing
erform tests, where the patch is
supposed to make significant changes.
So I would rely on your and the other reviewers results.
Except mentioned notes, I suppose the patch is good enough to pass it to
a reviewer.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
25.01.2016 03:32, Jeff Janes:
On Fri, Jan 22, 2016 at 7:19 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
Done. I hope that my patch is close to the commit too.
Thanks for the update.
I've run into this problem:
create table foobar (x text, w text);
create unique
us at all.
Maybe you should explain this magic number 7 in the comment above?
--
Anastasia Lubennikova
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 subscript
in while flushing pending list into the index?
Why not read this data directly from the table? I feel that I've missed
something important here.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-h
html
Since I haven't watched it closely, It seems to be open still. I think
it'll be interesting to you.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ures refactoring" as a separate patch.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 97ef618..d17a06c 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/do
ry to fix it and add expressions support a bit later.
--
Anastasia Lubennikova
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.org/mailpref/pgsql-hackers
to reproduce it
performing test with and whithot the patch.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
at the EXPLAIN
code to see how those are determined yet.
Hmm... Do you use both patches?
And could you provide index definition, I can't reproduce the problem
assuming that index is created by the statement
CREATE INDEX idx ON ab (a) INCLUDING (b);
--
Anastasia Lubennikova
Postgres
04.01.2016 11:49, David Rowley:
On 2 December 2015 at 01:53, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru <mailto:a.lubennik...@postgrespro.ru>>
wrote:
Finally, completed patch "covering_unique_3.0.patch" is here.
It includes the functionality discuss
x Only Scan using newidx on newt (cost=0.43..374.68 rows=1
width=8) (actual time=0.018..2.595 rows=6 loops=1)
Index Cond: (c1 < 1)
Filter: (c3 < 20)
Rows Removed by Filter: 9993
Heap Fetches: 0
Planning time: 0.078 ms
Execution time: 2.612 ms
--
Anastasia Lubennikova
Pos
03.12.2015 04:03, Robert Haas пишет:
On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
If we don't need c4 as an index scankey, we don't need any btree opclass on
it.
But we still want to have it in covering index for queries like
SELECT c4 FR
important.
Attrs which have oplass and want to use it in ScanKey must be situated
before the others.
idx2 will use c2 in IndexCond, while idx3 will not. But I think that
it's the job for DBA.
If you see any related changes in planner, please mention them. I
haven't explored that part of code yet an
08.10.2015 19:31, Thom Brown пишет:
On 8 October 2015 at 16:18, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> wrote:
Hi hackers,
I'm working on a patch that allows to combine covering and unique
functionality for btree indexes.
Previous discussion was here:
1) Proposal th
ave it in covering index for queries like
SELECT c4 FROM tbl WHERE c1=1000;
SELECT * FROM tbl WHERE c1=1000;
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
test.sql
Description: application/sql
diff --git a/src/backend/access/common/
in
gistvacuumpage(). Patch is attached.
But It seems to me that it would be better to rewrite all mentions of
TupleDelete to MultiDelete in gist code.
I'm working on it.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company()
diff --git a/src/backend/access
1 - 100 of 134 matches
Mail list logo
