Re: [HACKERS]WIP: Covering + unique indexes.

ture work. I found one more thing to do. Pgdump 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-hacker

Re: [HACKERS]WIP: Covering + unique indexes.

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

Re: [HACKERS]WIP: Covering + unique indexes.

01.03.2016 19:55, Anastasia Lubennikova: 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

Re: [HACKERS][PATCH] Supporting +-Infinity values by to_timestamp(float8)

bit sloppy * about the maximum, since it's far enough out to not be especially * 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 compatib

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

00 00 00 00 00 00 01 00 00 00 00 00 02 00 00 00 00 00 03 00 00 00 00 00 04 00 00 00 00 00 05 00 00 00 00 00 06 00 00 00 00 00 postgres=# 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

Re: [HACKERS]WIP: Covering + unique indexes.

02.03.2016 08:50, Michael Paquier: On Wed, Mar 2, 2016 at 2:10 AM, Anastasia Lubennikova 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. line 5466 if (fout->remoteVers

[HACKERS] Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

is boundary of isoyears -4713 and -4712). Is it worth to break undocumented range or leave 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

Re: [HACKERS] Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

15.03.2016 03:21, Vitaly Burovoy: On 3/14/16, Anastasia Lubennikova 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 fairly straight-forward bug fix (the size

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

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 wrote: I fixed it in the new version (attached). Thank you

Re: [HACKERS] [PATCH] Supporting +-Infinity values by to_timestamp(float8)

15.03.2016 22:28, David Steele: On 3/4/16 2:56 PM, Vitaly Burovoy wrote: On 3/4/16, Anastasia Lubennikova wrote: I think that you should update documentation. At least description of epoch on this page: http://www.postgresql.org/docs/devel/static/functions-datetime.html Thank you very much

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

g into pg_index, 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

Re: [HACKERS] WIP: Covering + unique indexes.

sid", so I'll take one bit of it. It will definitely require changes in the future 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 Lubennikov

Re: [HACKERS] WIP: Covering + unique indexes.

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 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 extensive review on the or

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

f you have any ideas related to this patch like prefix/suffix compression, 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 subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Supporting +-Infinity values by to_timestamp(float8)

17.03.2016 06:27, Vitaly Burovoy: On 2016-03-15, David Steele wrote: On 3/4/16 2:56 PM, Vitaly Burovoy wrote: On 3/4/16, Anastasia Lubennikova wrote: I think that you should update documentation. At least description of epoch on this page: http://www.postgresql.org/docs/devel/static

Re: [HACKERS]WIP: Covering + unique indexes.

------ Index 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 He

Re: [HACKERS]WIP: Covering + unique indexes.

performing test with and whithot the patch. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS]WIP: Covering + unique indexes.

I've not looked 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); -- Anast

Re: [HACKERS]WIP: Covering + unique indexes.

eel renaming that might cause a fair bit of code churn, so I'd be interested to hear what other's have to say. I agree that KeyAttrNumbers and indexkeys are a bit confusing names, but I'd like to keep them at least in this patch. It's may be worth doing "index stru

Re: [HACKERS]WIP: Covering + unique indexes.

'll try 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

Re: [HACKERS] Batch update of indexes

sion) There was the discussion of the patch for partial indexes. http://postgresql.nabble.com/PATCH-index-only-scans-with-partial-indexes-td5857568.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

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

itions do not look obvious 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

Re: [HACKERS] Batch update of indexes

pending list and then copy it again 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

Re: [HACKERS]WIP: Covering + unique indexes.

22.01.2016 01:47, David Rowley: On 20 January 2016 at 06:08, Anastasia Lubennikova wrote: 18.01.2016 01:02, David Rowley пишет: On 14 January 2016 at 08:24, David Rowley wrote: I will try to review the omit_opclass_4.0.patch soon. Hi, as promised, here's my review o

Re: [HACKERS]WIP: Covering + unique indexes.

25.01.2016 03:32, Jeff Janes: On Fri, Jan 22, 2016 at 7:19 AM, Anastasia Lubennikova 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 index foobar_pkey on foob

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

t I haven't any big machine to perform 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

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

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

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

28.01.2016 18:12, Thom Brown: On 28 January 2016 at 14:06, Anastasia Lubennikova 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 duplicate keys in B-tree index.

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

28.01.2016 20:03, Thom Brown: On 28 January 2016 at 16:12, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: 28.01.2016 18:12, Thom Brown: On 28 January 2016 at 14:06, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: 31.0

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

ied to reproduce 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 Profession

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

29.01.2016 20:43, Thom Brown: On 29 January 2016 at 16:50, Anastasia Lubennikova wrote: 29.01.2016 19:01, Thom Brown: On 29 January 2016 at 15:47, Aleksander Alekseev wrote: I tested this patch on x64 and ARM servers for a few hours today. The only problem I could find is that INSERT

Re: [HACKERS]WIP: Covering + unique indexes.

31.01.2016 11:04, David Rowley: On 27 January 2016 at 03:35, Anastasia Lubennikova 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 debug. Hi, I've made another pass ove

[HACKERS] Some refactoring of index structures .

ny ideas? If you see any 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

Re: [HACKERS]WIP: Covering + unique indexes.

02.02.2016 15:50, Anastasia Lubennikova: 31.01.2016 11:04, David Rowley: On 27 January 2016 at 03:35, Anastasia Lubennikova 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

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

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 wrote: I fixed it in the new version (attached). Thank you for the review. At last, there is a new patch version 3.0. After some refactoring it looks much

Re: [HACKERS] Pluggable storage

ompletion yet; expect things to change for items that I've overlooked, but I hope I didn't overlook any major. If things are handwavy, it is probably because I haven't fully figured them out yet. Thank you again for beginning the big project. Looking forward to the prototype. I th

Re: [HACKERS] Optimization for lazy_scan_heap

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 pret

Re: [HACKERS] Refactoring of heapam code.

06.09.2016 07:44, Pavan Deolasee: On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: Thank you for the review, I'll fix these problems in final version. Posting the first message I intended to raise the discussi

Re: [HACKERS] WIP: Covering + unique indexes.

28.08.2016 09:13, Amit Kapila: On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova wrote: @@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup) if (last_off == P_HIKEY) { Assert(state->btps_minkey == NULL); - state->btps_

Re: [HACKERS] sequences and pg_upgrade

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

Re: [HACKERS] WIP: Covering + unique indexes.

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

Re: [HACKERS] sequences and pg_upgrade

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(&dopt, tblinfo, numTables, dopt.oids);

[HACKERS] File system operations.

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

Re: [HACKERS] WIP: Covering + unique indexes.

24.09.2016 15:36, Amit Kapila: On Wed, Sep 21, 2016 at 6:51 PM, Anastasia Lubennikova wrote: 20.09.2016 08:21, Amit Kapila: On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova wrote: 28.08.2016 09:13, Amit Kapila: The problem seems really tricky, but the answer is simple. We store

Re: [HACKERS] sequences and pg_upgrade

But again, 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 */ -- Anast

Re: [HACKERS] WIP: Covering + unique indexes.

03.10.2016 05:22, Michael Paquier: On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova 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, which is fixed now (see the attac

Re: [HACKERS] WIP: Covering + unique indexes.

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 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 R

Re: [HACKERS] FSM corruption leading to errors

PR06MB504CD8FE8AA30D4B7C958AAE39E0%40AMSPR06MB504.eurprd06.prod.outlook.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 d

[HACKERS] Question about pg_control usage

requires 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 vi

Re: [HACKERS] IF NOT EXISTS option for CREATE SERVER and CREATE USER MAPPING statements

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 s

Re: [HACKERS] Backend crash on non-exclusive backup cancel

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: FailedAssertion

Re: [HACKERS] Backend crash on non-exclusive backup cancel

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 smal

Re: [HACKERS] btree_gin and btree_gist for enums

t" "/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 considered "Read

Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops

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. All

[HACKERS] Changes in amcanreturn() interface to support multicolumn indexes

Changes in amcanreturn() interface to support multicolumn indexes. Hi, hackers I work on GSoC project Support_for_Index-only_scans_for_GIST_GSoC_2014 There is a question of support multicolumn index only scans for GI

[HACKERS] Index-only scans for multicolumn GIST

Hi, hackers! There are new results of my work on GSoC project "Index-only scans for GIST". Previous post is here: http://postgresql.1045698.n5.nabble.com/Index-only-scans-for-GIST-td5804892.html Repository is https://github.com/lubennikovaav/postgres/tree/indexonlygist2 Patch is in attachments. It

[HACKERS] Index-only scans for GIST

Hi, hackers! I work on a GSoC project "Index-only scans for GIST" https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014 Repository is https://github.com/lubennikovaav/postgres/tree/indexonlygist2 Patch is in attachments. It includes index-only scans for multicolumn GIST

Re: [HACKERS] Index-only scans for GIST

Thank you for comment Patch is already added in Performance topic. 2014-08-01 20:25 GMT+04:00 Fabrízio de Royes Mello : > > On Fri, Aug 1, 2014 at 4:58 AM, Anastasia Lubennikova < > lubennikov...@gmail.com> wrote: > > > > Hi, hackers! > > I work on a GSoC p

Re: [HACKERS] Index-only scans for GIST

2014-08-07 0:30 GMT+04:00 Heikki Linnakangas : * I'm getting two regression failures with this (opr_sanity and join). > opr_sanity failure is corrected. But there is remain question with join. I check the latest version of my github repo and there's no fail in join regression test All 145 tests p

Re: [HACKERS] Index-only scans for GIST

Updated patch * Compiler, merge and regression fails checked * Regression tests was impoved * GiST and amcanreturn docs updated -- Best regards, Lubennikova Anastasia indexonlyscan_gist2.patch Description: Binary data indexonlyscan_gist_docs.patch Description: Binary data -- Sent via pgsql-h

Re: [HACKERS] WIP: Covering + unique indexes.

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 Date: Tue Mar 21 12:58:13 2017 +0300 include_columns_10.0_v4

[HACKERS] Re: Declarative partitioning optimization for large amount of partitions

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 te

Re: [HACKERS] pg_serial early wraparound

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 esse

Re: [HACKERS] WIP: Covering + unique indexes.

e do need it. */ That is not a very informative 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 mailin

Re: [HACKERS] WIP: Covering + unique indexes.

orm_tuple() calls. But index_form_tuple_extended() looks like a better solution. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] WIP: Covering + unique indexes.

31.03.2017 20:57, Robert Haas: On Fri, Mar 31, 2017 at 1:40 PM, Anastasia Lubennikova 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 wonder, why don't you share your tho

Re: [HACKERS] WIP: Covering + unique indexes.

No? I changed it. Now we always use highkey saved in xlog. This 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

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

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 c

[HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

Hi, I'm working on microvacuum for gist access method. Briefly microvacuum includes two steps: 1. When search tells us that the tuple is invisible to all transactions it is marked LP_DEAD and page is marked as "has dead tuples", 2. Then, when insert touches full page which has dead tuples it calls

Re: [HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

2015-07-27 20:05 GMT+04:00 Heikki Linnakangas : > On 07/27/2015 06:46 PM, Teodor Sigaev wrote: > >> I need an advice, what would be better: >>> - to add new flag like F_HAS_GARBAGE, >>> - or to delete all mentions of F_TUPLES_DELETED and use it in gist >>> microvacuum. >>> >> >> According to commi

[HACKERS] [PATCH] Microvacuum for gist.

Hi, I have written microvacuum support for gist access method. Briefly microvacuum includes two steps: 1. When search tells us that the tuple is invisible to all transactions it is marked LP_DEAD and page is marked as "has dead tuples", 2. Then, when insert touches full page which has dead tuples

Re: [HACKERS] [PATCH] Microvacuum for gist.

30.07.2015 16:33, Alexander Korotkov пишет: Hi! On Thu, Jul 30, 2015 at 2:51 PM, Anastasia Lubennikova mailto:lubennikov...@gmail.com>> wrote: I have written microvacuum support for gist access method. Briefly microvacuum includes two steps: 1. When search tells us th

Re: [HACKERS] [PATCH] Microvacuum for gist.

On Mon, Aug 3, 2015 at 12:27 PM, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: 1) Test and results are in attachments. Everything seems to work as expected. 2) I dropped these notices. It was done only for debug purposes. Updated patch is attached.

Re: [HACKERS] How to compare different datums within from a tuple?

> > Can someone tell me, how I can compare two datum fields, when I do not > know the data type in advance inside an executor function? > In a nutshell, there is no way to compare Datums. Datum is an abstact data type. It's the backend internal representation of a single value of any SQL data type

[HACKERS] [PROPOSAL] Effective storage of duplicates in B-tree index.

s to do microvacuum of posting list/tree. Which one is better? -- Anastasia Lubennikova Postgres Professional:http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Adding since-version tags to the docs?

e patch author. Do you think such approach will work? Is there interest in having this done? -- Alex I think that you're looking for Feature matrix <http://www.postgresql.org/about/featurematrix/>. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Should \o mean "everything?"

uot; includes <...> output of various backslash commands that query the database (such as \d), | but not error messages. As I understand, this phrase means ONLY those commands which starts with '\d' (such as \dt, \di, \des etc.) -- Anastasia Lubennikova Postgres Professio

Re: [HACKERS] [PATCH] Microvacuum for gist.

Hi, I don't know too much about gist, but did a quick read through. Mostly spotting some stylistic issues. Please fix those making it easier for the next reviewer. Thank you for review! All mentioned issues are fixed. -- Anastasia Lubennikova Postgres Professional:http://www.postgrespr

Re: [HACKERS] [PROPOSAL] Effective storage of duplicates in B-tree index.

01.09.2015 21:23, Peter Geoghegan: On Mon, Aug 31, 2015 at 12:41 AM, Anastasia Lubennikova wrote: Now new B-tree index tuple must be inserted for each table row that we index. It can possibly cause page split. Because of MVCC even unique index could contain duplicates. Storing duplicates in

Re: [HACKERS] PATCH: index-only scans with partial indexes

the index->indpred, so it is impossible to recheck qual without referencing to table. In example: create index tidx_partial on t(a) where a > 1000 and a < 2000; explain analyze select sum(a) from t where a > 1000 and a < 1999; it can use IndexOnlyScan. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] [PATCH] Microvacuum for gist.

t following queries are executed significantly faster than without microvacuum. Time: 368,780 ms Time: 69,769 ms Time: 9,545 ms Time: 12,427 ms Please, review the patch again. I could have missed something. P.S. Do I need to write any documentation update? -- Anastasia Lubennikova Postgres Pro

Re: [HACKERS] [PATCH] Microvacuum for gist.

: 354,097 ms Time: 82,206 ms Time: 11,714 ms Time: 11,277 ms -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/access/gist/gist.c b/src/backend/access/gist/gist.c index 0e49959..bb48782 100644 --- a/src/backend/access/gist

[HACKERS][PROPOSAL] Covering + unique indexes.

of first columns of index which has unique constrains. */ I think, that numbers of all attributes themselves are not needed. Is it right? I'd like to see your suggestions about syntax changes. And of course any other comments are welcome. -- Anastasia Lubennikova Postgres Professional:

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

15.09.2015 12:18, David Rowley: On 12 September 2015 at 00:45, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: I've started work on a patch that allows to combine covering and unique functionality. Great to hear someone is working on this! Thank yo

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

to me. It refers to CTE, so I expect to see after that a kind of query expression. But maybe that's just matter of habit. BTW, that's the first syntax change I'm working with. Is there any convention in PostgreSQL about new keywords and so on? Where can I find it? -- Anastasia

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

ex is not unique */ int16 ind_n_key_atts; /* number of index key columns in index. counted from begin of index.*/ int16 ind_n_total_atts; /* number of columns in index.*/ In our case: ind_n_unique_atts = 2; // f1, f2 ind_n_key_atts = 3; // f1, f2, f3 ind_n_total_atts = 4; // f1, f2, f3, f4 P.S. I

Re: [HACKERS] [PATCH] Microvacuum for gist.

hange MultiDelete to TupleDelete 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 C

[HACKERS]WIP: Covering + unique indexes.

need any btree opclass on it. But we still want to have 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:

Re: [HACKERS]WIP: Covering + unique indexes.

08.10.2015 19:31, Thom Brown пишет: On 8 October 2015 at 16:18, Anastasia Lubennikova 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 thread 2) Message with pro

[HACKERS] GSoC 2015 proposal. Bitmap Index-only Count

Hi, hackers! Here is the text of my proposal which I've applied to GSoC. (and link http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/lubennikovaav/5657382461898752 ) Any suggestions and comments are welcome. *Project name* Bitmap Index-only Count *Brief review* There is a p

Re: [HACKERS] GSoC 2015 proposal. Bitmap Index-only Count

2015-03-24 18:01 GMT+04:00 Tom Lane : > Anastasia Lubennikova writes: > > There is a problem of slow counting in PostgreSQL [1]. The reason why > this > > is slow is related to the *MVCC* implementation in PostgreSQL. Index-only > > scans (implemented since Postgr

Re: [HACKERS]WIP: Covering + unique indexes.

G (c4, c2); Of course, order of attributes is 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 men

Re: [HACKERS]WIP: Covering + unique indexes.

03.12.2015 04:03, Robert Haas пишет: On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova 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 FROM tbl WHERE c1=1000; /

Re: [HACKERS]WIP: Covering + unique indexes.

04.01.2016 11:49, David Rowley: On 2 December 2015 at 01:53, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: Finally, completed patch "covering_unique_3.0.patch" is here. It includes the functionality discussed above in the thread, regressio

[HACKERS] IF NOT EXISTS option for CREATE SERVER and CREATE USER MAPPING statements

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

Re: [HACKERS] Parallel Index Scans

27.12.2016 17:33, Amit Kapila: On Fri, Dec 23, 2016 at 6:42 PM, Anastasia Lubennikova wrote: 22.12.2016 07:19, Amit Kapila: On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova wrote: The following review has been posted through the commitfest application: make installcheck-world: tested

Re: [HACKERS] GSoC 2017

soc/timeline -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

patch. Hope to see it in 10.0. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

[HACKERS] Cast jsonb to numeric, int, float, bool

dback. If you find it useful, I can also 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 b

Re: [HACKERS] IF NOT EXISTS option for CREATE SERVER and CREATE USER MAPPING statements

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

  1   2   >