Re: Covering GiST indexes

Hi! > 13 апр. 2018 г., в 17:36, Andrey Borodin написал(а): > > Here's V2, with basic set of tests. > Currently, I'm investigating what to document and more places to tests. Here is v3 version of the patch. I've fixed some comments and added some words to docs. B

Re: [HACKERS] [PATCH] kNN for SP-GiST

ance function is lossy"); Some small typos: usefull -> useful nearest-neighbour -> nearest-neighbor (or do we use e.g. "colour"?) Best regards, Andrey Borodin.

Re: [PG-11] Potential bug related to INCLUDE clause of CREATE INDEX

. "ERROR: including column does not support ASC/DESC options" and "ERROR: including column does not support NULLS FIRST/LAST options". IMHO it is not a bug. CREATE INDEX ON some_table(id+0) INCLUDE (id); or some similar tricks will work anyway. Best regards, Andrey Borodin.

Re: [HACKERS] [PATCH] kNN for SP-GiST

stack and queue? Best regards, Andrey Borodin. [0] https://commitfest.postgresql.org/14/1215/

Re: GiST VACUUM

good. I was considering doing reverse-split (page merge) concurrency like in Lanin and Shasha's paper, but it is just too complex for little purpose. Will add comments on possible orphan pages. Many thanks! I hope to post updated patch series this week. Best regards, Andrey Borodin.

Re: GiST VACUUM

ceptable, but a comment at least > would be good. Added explanatory comment between WAL-logging downlink removal and marking pages deleted. Thank you for reviewing the patch! Best regards, Andrey Borodin. 0002-Physical-GiST-scan-during-VACUUM-v5.patch Description: Binary data 0001-Delete-pages-during-GiST-VACUUM-v5.patch Description: Binary data

Re: GiST VACUUM

> 12 июля 2018 г., в 20:40, Heikki Linnakangas написал(а): > > On 12/07/18 19:06, Andrey Borodin wrote: >>> 11 июля 2018 г., в 0:07, Heikki Linnakangas >>> написал(а): >>> This seems misplaced. This code deals with internal pages, and as >>> far

Re: GiST VACUUM

Hi!PFA v6 of the patch.12 июля 2018 г., в 21:07, Andrey Borodin <x4...@yandex-team.ru> написал(а):12 июля 2018 г., в 20:40, Heikki Linnakangas <hlinn...@iki.fi> написал(а):Actually, now that I think about it more, I'm not happy with leaving orphaned pages like that behind.

Re: GiST VACUUM

something similar in the physical scan: remember the > current LSN position at the beginning of the vacuum, and compare with that. > The B-tree code uses the "cycle ID" for similar purposes. > > Do we still need the separate gistvacuumcleanup() pass, if we scan the

Re: GiST VACUUM

> 14 июля 2018 г., в 0:28, Heikki Linnakangas написал(а): > > On 13/07/18 21:28, Andrey Borodin wrote: >>> 13 июля 2018 г., в 18:25, Heikki Linnakangas >>> написал(а): >>> Looking at the second patch, to scan the GiST index in physical >>> order

Re: GiST VACUUM

> 14 июля 2018 г., в 14:39, Heikki Linnakangas написал(а): > > On 14/07/18 10:26, Andrey Borodin wrote: >> This is tradeoff between complex concurrency feature and possibility >> of few dead tuples left after VACUUM. I want to understand: is it >> something da

Re: [HACKERS] [PATCH] kNN for SP-GiST

if (innerTuple->allTheSame) + if (out.nNodes != 0 && out.nNodes != nNodes) + elog(ERROR, "inconsistent inner_consistent results for allTheSame inner tuple"); + + if (out.nNodes) // few lines before you compare with 0 Best regards, Andrey Borodin.

Re: GiST VACUUM

purpose) have their > own associated scariness. Thanks, that's exactly what I'm thinking about where to store this xid. Here's v9 of the patch, it uses pd_prune_xid, but it is abstracted to GistPageGetDeleteXid() \ GistPageSetDeleteXid() so that we can change the way we store i

Re: Alter index rename concurrently to

t cover one very important topic. When we use CREATE INDEX CONCURRENTLY we pay for less intrusive lock by scanning data twice. What is the price of RENAME CONCURRENTLY? Should this mode be default? Best regards, Andrey Borodin.

Re: GiST VACUUM

Hi! > 16 июля 2018 г., в 21:24, Andrey Borodin написал(а): > I was checking WAL replay of new scheme to log page deletes and found a bug there (incorrect value of deleted downlink in WAL record). Here's fixed patch v10. Also I've added support to WAL identification for new r

Re: GSOC 2018 Project - A New Sorting Routine

Hi, Tomas! > 15 июля 2018 г., в 1:20, Tomas Vondra > написал(а): > > So I doubt it's this, but I've tweaked the scripts to also set this GUC > and restarted the tests on both machines. Let's see what that does. Do you observe any different results? Thanks! Best regards, Andrey Borodin.

Re: [Patch] Checksums for SLRU files

g_upgrade tests but didn't found one. Should it be one-time test script or something "make check-world"-able? Best regards, Andrey Borodin.

Re: GiST VACUUM

is very simple. All work is done in one cycle, without memorizing anything. Actually, you do not even need to rescan rightlinks: there may be no splits to the left when no pages are deleted. If you think it is proper way to go - OK, I'll prepare better version of attached diff (by omitting tail recursion and adding more comments). Best regards, Andrey Borodin. gist_phisical_vacuum_v1.diff Description: Binary data

Re: GiST VACUUM

fs. Second physical scan only reads internal pages. I can omit that bitmap, if I'll scan everything. Also, I can replace emptyLeafs bitmap with array\list, but I do not really think it will be big. Anyway I propose focusing on first step. Best regards, Andrey Borodin. 0002-Delete-page

Re: GiST VACUUM

19.07.2018, 15:20, "Heikki Linnakangas" :On 19/07/18 13:52, Andrey Borodin wrote: Hi! 19 июля 2018 г., в 1:12, Heikki Linnakangas <hlinn...@iki.fi> написал(а): Yeah, please, I think this is the way to go. Here's v11 divided into proposed steps.Thank

Re: GiST VACUUM

n that page either before, or after the split. If we scan > the single page before the split, we see all the leaf tuples on that page. If > we scan the single page after the split, it means that we start the scan > after the split, and we will see both leaf pages as we continue the scan. Yes, only page 0 may change type, and page 0 cannot split to left. I'm working on triggering left split during vacuum. Will get back when done. Thanks! Best regards, Andrey Borodin.

Re: GiST VACUUM

Hi! > 19 июля 2018 г., в 23:26, Andrey Borodin написал(а): > > I'm working on triggering left split during vacuum. Will get back when done. > Thanks! Here's patch including some messy hacks to trigger NSN and FollowRight jumps during VACUUM. To trigger FollowRight Gi

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

Hi! > 15 нояб. 2018 г., в 17:30, Andrey Borodin написал(а): > > I think I can compose patch for consideration. I found no practical way to fix concept of "subtree-lock". Pre-locking all left siblings for cleanup would suffice, but does not look very practical. GIN Post

Re: B-tree cache prefetches

seems to be winner. How can I improve experimental evaluation of these layout strategies? Other thoughts? I'd be happy to hear any comment on this. Best regards, Andrey Borodin. 0001-Implement-different-B-tree-page-layouts.patch Description: Binary data

Re: Covering GiST indexes

lease rebase it one more time? Here's rebased version. Thanks! Best regards, Andrey Borodin. 0001-Covering-GiST-v5.patch Description: Binary data

Re: [HACKERS] Can ICU be used for a database's default sort order?

Hi, Dmitry, Daniel! > 2 дек. 2018 г., в 17:22, Dmitry Dolgov <9erthali...@gmail.com> написал(а): > >> There were reviews: Andrey Borodin raised issues with the patch in >> [2], I spent some time trying it and asked questions about the design >> in [3], but no one

Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)

о быть суперпользователем"? Where do we insert FOR ALL TABLES? 4. How does default behavior differ from FOR ALL TABLES? 5. Can we alter subscription FOR ALL TABLES? Drop some tables out of the subscription? Best regards, Andrey Borodin.

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

tree for cleanup. PFA diff with following changes: 1. Always take root cleanup lock before deleting pages 2. Check for concurrent splits after scanning page Please note, that neither applying this diff nor reverting 218f51584d5 will solve bug of page delete redo lock on standby. Best regards, Andrey Borodin. gin_root_lock.diff Description: Binary data

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

he page before TransactionIdPrecedes(GinPageGetDeleteXid(page), RecentGlobalDataXmin). Should we leave alone this bug for future fixes to keep current fix noninvasive? Best regards, Andrey Borodin.

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

avior? It seems to me that locking order must be left->deleted->parent. Best regards, Andrey Borodin.

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

> 10 дек. 2018 г., в 18:56, Andrey Borodin написал(а): > > PFA this part. In thread about GiST vacuum Heikki was not very happy with > reusing PageHeader->pd_prune_xid for this. But we somewhat concluded that > this might be OK. > Anyway, there's whole page, we can

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

ePage is never set. Sorry, I've messed it again. Forgot to include ginvacuum.c changes. Here it is. Best regards, Andrey Borodin. 0001-Stamp-deleted-GIN-page-with-xid-v2.patch Description: Binary data

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

ecks this condition both before putting page into FSM and > after getting page from FSM. You're checking only after getting page > from FSM. Approach of B-tree looks better for me. It's seems more > consistent when FSM pages are really free for usage. Fixed. Best regards, Andrey

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

ed Hat 4.4.7-23) That's the same variable, one place is definition while other is potential misuse. Seems like these 2 lines [0] + if (BufferIsValid(lbuffer)) + UnlockReleaseBuffer(lbuffer); are superfluous: lbuffer is UnlockReleased earlier. Best regards, Andrey Borodin. [0] https://github.com/postgres/postgres/commit/19cf52e6cc33b9e126775f28269b6ddf7e30#diff-ed6446a8993c76d2884ec6413e49a6b6R757

Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)

se, avoid top-posting (quoting whole message under your reply), this makes harder to read archives at postgresql.org And also please send patches with version number to distinguish old and new versions. Best regards, Andrey Borodin.

Re: amcheck verification for GiST

Hi, Peter! Thank you for the review! > 7 дек. 2018 г., в 3:59, Peter Geoghegan написал(а): > > On Sun, Sep 23, 2018 at 10:12 PM Andrey Borodin wrote: > * You do this: > >> +/* Check of an internal page. Hold locks on two pages at a time >> (parent+child). */ >

Re: GiST VACUUM

ent to GistPageSetDeleteXid() * In this check > if (GistPageIsDeleted(page) && > TransactionIdPrecedes(GistPageGetDeleteXid(page), RecentGlobalXmin)) I've switched using RecentGlobalDataXmin to RecentGlobalXmin, because we have done so in similar mechanics for GIN (for uniformity with B-tree). Thanks for working on this! Best regards, Andrey Borodin. 0002-Delete-pages-during-GiST-VACUUM-v19.patch Description: Binary data 0001-Physical-GiST-scan-in-VACUUM-v19.patch Description: Binary data

Re: GiST VACUUM

3 янв. 2019 г., в 23:47, Andrey Borodin написал(а): > >> * Bitmapset stores 32 bit signed integers, but BlockNumber is unsigned. So >> this will fail with an index larger than 2^31 blocks. That's perhaps >> academical, I don't think anyone will try to create

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

so, let's comment about it. 3. RestoreArchivedFile() checks for signals, is it done by pg_rewind elsewhere? 4. No documentation is updated 5. -R takes precedence over -r without notes. Shouldn't we complain? Or may be we should take one from config, iif nothing found use -R? Thanks! Best regards, Andrey Borodin.

Re: commitfest: When are you assigned patches to review?

Hi everyone! > 8 янв. 2019 г., в 14:14, Fabien COELHO написал(а): > > The process is that *you* choose the patches to review and register as such > for the patch on the CF app. By the way, is it ok to negotiate review exchange? Best regards, Andrey Borodin.

Re: GSoC 2019

o single project. Vladimir had done 2018's WAL-G project during Yandex internship, so I'll remove this project from page. Best regards, Andrey Borodin.

Re: O_DIRECT for relations and SLRUs (Prototype)

hings get significantly slower. Cool! I've just gathered a group of students to task them with experimenting with shared buffer eviction algorithms during their February internship at Yandex-Sirius edu project. Your patch seems very handy for benchmarks in this area. Thanks! Best regards, Andrey Borodin.

Re: O_DIRECT for relations and SLRUs (Prototype)

e is done wrong" due to really bad performance. Best regards, Andrey Borodin.

Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)

n preset subscription" Should it be "table does not present in subscription"? Besides this, patch looks good to me. Thanks for working on this! Best regards, Andrey Borodin.

Re: O_DIRECT for relations and SLRUs (Prototype)

gt; aligned with the OS pages, which should be 4k for Linux by the way, > and not set to BLCKSZ, but for WAL's O_DIRECT we don't really care > much with such details. Is it possible to avoid those memcopy's by aligning available buffers instead? I couldn't understand this from

Re: [GSoC] application ideas

Hi! We are discussing GSoC details offlist, but I'll put some recommendations on your proposal to the list. > 3 апр. 2019 г., в 2:53, pantilimonov misha написал(а): > > Andrey, thank you for your reply. > >> 24.03.2019, 12:12, "Andrey Borodin" : >>

Re: GiST VACUUM

Hi! > 4 апр. 2019 г., в 20:15, Heikki Linnakangas написал(а): > > On 25/03/2019 15:20, Heikki Linnakangas wrote: >> On 24/03/2019 18:50, Andrey Borodin wrote: >>> I was working on new version of gist check in amcheck and understand one >>> more thing: >>

Re: Google Summer of Code: question about GiST API advancement project

happens with geo data, all points have same height above ocean) if always have zero volume of MBB. BTW look at PostGIS, they are main GiST users, so indexing their data is important. Best regards, Andrey Borodin.

Re: Google Summer of Code: question about GiST API advancement project

part, it is MR subsystem. Best regards, Andrey Borodin.

Re: Compressed TOAST Slicing

Hi! > 12 марта 2019 г., в 10:22, Andrey Borodin написал(а): > > 3. And I'd use memmove despite the comment why we do not do that. It is > SSE-optimized and cache-optimized nowadays. So, I've pushed idea a little bit and showed that decompress byte-copy cycle to Vladi

Re: Compressed TOAST Slicing

e very synthetic. Do we have a natural way to demonstrate a performance improvement? Like reference pile of bytes... Best regards, Andrey Borodin.

Re: Compressed TOAST Slicing

^ copy here three bytes memmove will give 01012 but we want 01010 ^ this 0 is taken from result of overwrite by first byte move. Best regards, Andrey Borodin.

Re: block-level incremental backup

here is no code. If > this proposal, or some modified version of it, seems likely to be > acceptable, I and/or my colleagues might try to implement it. I'll be happy to help with code, discussion and patch review. Best regards, Andrey Borodin. [0] https://yadi.sk/i/Y_S1iqNN5WxS6A

Re: GSOC 2019 proposal 'WAL-G safety features'

AL-G is hosted under PostgreSQL umbrella. Thanks! Best regards, Andrey Borodin.

Re: Compressed TOAST Slicing

on to compare decompression time on pgbench-generated WAL [0] Use of smart memcpy unless match length is smaller than 16 (sane random value) gives about 20% speedup to decompression time. Sole use of memcpy gives smaller effect. We will dig into this further. Best regards, Andrey Borodin. [0] https://github.com/x4m/test_pglz

Re: block-level incremental backup

aturated IO controllers. Also I think parallel restore matters more than parallel backup. Backups themself can be slow, on many clusters we even throttle disk IO. But users may want parallel backup to catch-up standby. Thanks. Best regards, Andrey Borodin.

Re: block-level incremental backup

> 21 апр. 2019 г., в 1:13, Robert Haas написал(а): > > On Sat, Apr 20, 2019 at 12:44 PM Andrey Borodin wrote: >> Incremental backup of 1Tb DB made with distance of few minutes (small change >> set) is few Gbs. All of this size is made of FSM (no LSN) and VM (hard to

Re: Global snapshots

clusters even if they provide global snapshot capabilities. I think we can have pretty elegant Point-in-CSN-Recovery here, right? If we want a group of clusters to recover to a globally consistent state. Best regards, Andrey Borodin.

Re: Do PostgreSQL have map and set structure(like STL in C++)?

tree in lib/rbtree.h [1] It's usual red-black tree. Best regards, Andrey Borodin. [0] https://github.com/postgres/postgres/blob/master/src/include/utils/hsearch.h [1] https://github.com/postgres/postgres/blob/master/src/include/lib/rbtree.h

Re: [HACKERS] Detrimental performance impact of ringbuffers on performance

stic that > can't be disabled, yielding massive slowdowns, really sucks. If we will have scan-resistant shared buffers eviction strategy [0] - we will not need ring buffers unconditionally. Are there any other reasons to have these rings? Best regards, Andrey Borodin. [0] https://www.po

pglz performance

rs and few laptops\desktops with intel CPUs 3. If compression is 30 times slower, should we better focus on compression instead of decompression? Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/CANP8%2BjKcGj-JYzEawS%2BCUZnfeGKq4T5LswcswMP4GUHeZEP1ag%40mail.gmail.com

Re: pglz performance

is statistically indistinguishable between hacked and original versions. Hacked decompression of data file is 2x faster. We are going to try these tests on cascade lake processors too. Best regards, Andrey Borodin.

Re: pglz performance

> 15 мая 2019 г., в 15:06, Andrey Borodin написал(а): > > Owners of AMD and ARM devices are welcome. Yandex hardware RND guys gave me ARM server and Power9 server. They are looking for AMD and some new Intel boxes. Meanwhile I made some enhancements to test suit: 1. I've add

Re: pglz performance

ly eager to see a patch with at least a > 10% improvement which remains simple, even more if it simplifies the > logic used in pglz. Here are patches for both winning versions. I'll place them on CF. My gut feeling is pglz_decompress_hacked8 should be better, but on most architectures b

Re: pglz performance

r byte. 00010006 Entropy = 1.450059 bits per byte. 00010001 Entropy = 2.944235 bits per byte. shakespeare.txt Entropy = 3.603659 bits per byte 16398 Entropy = 1.897640 bits per byte. Best regards, Andrey Borodin.

Re: GiST limits on contrib/cube with dimension > 100?

ly, tuples should not be bigger than half of usable page space. Best regards, Andrey Borodin.

Re: GiST limits on contrib/cube with dimension > 100?

th specialized indexes that only do ANN. Yet, as far as I know, no one really pursued the idea of fast high dimensional ANN in PG. Best regards, Andrey Borodin.

amcheck verification for GiST

tree invariants due to concurrency reasons some concurrent splits will be visible as temporary balance violations. Are there any other invariants that we can check? I'd be happy to hear any thought about this. Best regards, Andrey Borodin. 0001-GiST-verification-function-for-amcheck.patch D

Re: amcheck verification for GiST

Hi! > 24 сент. 2018 г., в 8:29, Thomas Munro > написал(а): > > On Sun, Sep 23, 2018 at 10:15 PM Andrey Borodin wrote: >> Here's the patch with amcheck functionality for GiST. > > Hi Andrey, > > Windows doesn't like it[1]: Thanks, Thomas! Yes,

Re: Global snapshots

tically is kind of dangerous... Also, currently hanging 2pc transaction can cause a lot of headache for DBA. Can we have some kind of protection for the case when one node is gone permanently during transaction? Thanks! Best regards, Andrey Borodin.

Re: [WIP PATCH] Index scan offset optimisation using visibility map

ost no > feedback since 20 Mar after patch design was changed :) > But seriously - I still working on it Let's move this to CF 2018-11? Obviously, it is WiP, but it seems that patch is being discussed, author cares about it. Best regards, Andrey Borodin.

Re: Experimenting with hash join prefetch

Hi, Thomas! > 14 окт. 2018 г., в 9:18, Thomas Munro > написал(а): > > + /* Prefetch the bucket for the next key */ > + uint32 next_hash = hash_uint32(DatumGetInt32(keyval) + 1); > + uint32 next_bucket = next_hash % hashtable->nbuckets; > +

Re: B-tree cache prefetches

-tree binsearch: thier data items are small and do not represent reference to actual data. Eytzinger exploits the fact that two posiible future keys share same cache line. But it is hard to provide, given we place items at quite random place of the page. Best regards, Andrey Borodin.

Re: B-tree cache prefetches

> 15 окт. 2018 г., в 2:38, Thomas Munro > написал(а): > > On Mon, Oct 15, 2018 at 12:03 AM Andrey Borodin wrote: >> 31 авг. 2018 г., в 2:40, Thomas Munro >> написал(а): >> A related topic is the cache-unfriendliness of traditional binary >> search

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

else > came to mind. It is also possible to leave the only one option -- passing > restore_command as command line argument. > I think it is better to load restore_command from recovery.conf. I didn't actually try patch yet, but the idea seems interesting. Will you add it to the commitfest? Best regards, Andrey Borodin.

Re: GiST VACUUM

Hi everyone! > 2 окт. 2018 г., в 6:14, Michael Paquier написал(а): > Andrey, your latest patch does not apply. I am moving this to the next > CF, waiting for your input. I'm doing preps for CF. Here's rebased version. Best regards, Andrey Borodin. 0002-Delete-pages-dur

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Hi, Alexey! > 25 окт. 2018 г., в 17:37, Alexey Kondratov > написал(а): Will you add this patch to CF? I'm going to review it. Best regards, Andrey Borodin

Re: Connection limit doesn't work for superuser

restrictions within the database. Do we consider connection limit "access restriction"? Superuser can avoid setting his connection limit if he do not need it. Best regards, Andrey Borodin.

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

be change from "dbuffer->pbuffer->lbuffer" to "lbuffer->dbuffer->pbuffer" . Is this right?This looks correct to me.Best regards, Andrey Borodin.

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

Hi! Mail.App somehow borken my reponse with , which is far beyond of my understanding of what is plain text, that's why I'll quote all my previous message here. Hope this mail client is OK. 14.11.2018, 23:13, "Andrey Borodin" : > Hi everyone! > > I didn'

Re: GiST VACUUM

Hi! > 21 июля 2018 г., в 17:11, Andrey Borodin написал(а): > > <0001-Physical-GiST-scan-in-VACUUM-v13.patch> Just in case, here's second part of patch series with actual page deletion. I was considering further decreasing memory footprint by using bloom filters instead of

Re: [HACKERS] [PATCH] kNN for SP-GiST

rect +extern BOX *box_copy(const BOX *box); I'm not sure in architectural point of view: supporting two ways (list and heap) to store result seems may be a bit heavy, but OK. At least, it has meaningful benefits. I think the patch is ready for committer. Best regards, Andrey Borodin.

Re: Covering GiST indexes

Hi, Thomas!29 июля 2018 г., в 14:28, Thomas Munro <thomas.mu...@enterprisedb.com> написал(а):On Fri, Jul 6, 2018 at 5:27 AM, Andrey Borodin <x4...@yandex-team.ru> wrote:Here is v3 version of the patch. I've fixed some comments and added some words to docs.Hi again Andrey,C

Re: GiST VACUUM

Hi! Thank you! > 29 июля 2018 г., в 14:04, Thomas Munro > написал(а): > > On Tue, Jul 24, 2018 at 6:04 AM, Andrey Borodin wrote: >>> 21 июля 2018 г., в 17:11, Andrey Borodin написал(а): >>> <0001-Physical-GiST-scan-in-VACUUM-v13.patch> >> >>

Re: Covering GiST indexes

Thanks, Thomas! > 30 июля 2018 г., в 3:58, Thomas Munro > написал(а): > > On Sun, Jul 29, 2018 at 10:50 PM, Andrey Borodin wrote: >> Thanks! The problem appeared with commit 701fd0b [0] which dropped >> validation rules checked in failed test. Here's the patch

Re: GiST VACUUM

Hi! Thanks for looking into the patch! > 30 июля 2018 г., в 18:39, Heikki Linnakangas написал(а): > > On 29/07/18 14:47, Andrey Borodin wrote: >> Fixed both problems. PFA v14. > > Thanks, took a really quick look at this. > > The text being added to README is outdat

Re: [Patch] Checksums for SLRU files

out preventing writing bad writes. But adding LSNs, and whole regular PageHeader is quite easy in this patch. Do you think we should really go that way? Putting SLRUs into usual shared buffers and WAL-logging looks like a good idea, but a lot of work. Best regards, Andrey Borodin.

Re: GiST VACUUM

Hi! > 5 авг. 2018 г., в 16:18, Heikki Linnakangas написал(а): > > On 31/07/18 23:06, Andrey Borodin wrote: >>> On a typical GiST index, what's the ratio of leaf vs. internal >>> pages? Perhaps an array would indeed be better. > > >> Typical GiST h

Re: GiST VACUUM

Hi! PFA v16. > 5 авг. 2018 г., в 21:45, Andrey Borodin написал(а): >> 5 авг. 2018 г., в 16:18, Heikki Linnakangas написал(а): >> >> Hmm. A ListCell is 16 bytes, plus the AllocChunk header, 16 bytes. 32 >> bytes per internal page in total, while a bitmap consumes on

Re: Proposal: SLRU to Buffer Cache

ng something, but why this should not be in access methods? You can extend AM to control it's segment size and ability to truncate unneeded pages. This may to be useful, for example, in LSM tree implementation or something similar. Best regards, Andrey Borodin.

Re: Dimension limit in contrib/cube (dump/restore hazard?)

de(ERRCODE_ARRAY_ELEMENT_ERROR), +errmsg("A cube cannot have more than %d dimensions.", + CUBE_MAX_DIM))); dur = ARRPTR(ur); Best regards, Andrey Borodin.

Re: Dimension limit in contrib/cube (dump/restore hazard?)

> 28 авг. 2018 г., в 14:18, Alexander Korotkov > написал(а): > > OK, but I think cube_c_f8() and cube_c_f8_f8() also need to be > revised. Also, I think this behavior should be covered by regression > tests. True. Also there's one case in cube_subset. Best

Re: Would it be possible to have parallel archiving?

e. Indeed, it was very hard to test. Also, this makes impossible to use two archiving system simultaneously for transit period. Best regards, Andrey Borodin.

Re: Would it be possible to have parallel archiving?

> 28 авг. 2018 г., в 17:07, Stephen Frost написал(а): > > Greetings, > > * Andrey Borodin (x4...@yandex-team.ru) wrote: >>> 28 авг. 2018 г., в 14:08, Stephen Frost написал(а): >>> * David Steele (da...@pgmasters.net <mailto:da...@pgmasters.net>) wrote:

Re: Would it be possible to have parallel archiving?

thod will stay safe forever. But now it is. Best regards, Andrey Borodin.

Re: A strange GiST error message or fillfactor of GiST build

t; After the attached patch applied, the above messages becomes as > follows. (And index can be built being a bit sparse by fill > factor.) We are passing freespace everywhere. Also, we pass GistInsertState, and GistState. Maybe let's put GistState into GistInsertState, GistState already has free space, and pass just GistInsertState everywhere? Best regards, Andrey Borodin.

Re: A strange GiST error message or fillfactor of GiST build

Hello! > 30 авг. 2018 г., в 2:42, Kyotaro HORIGUCHI > написал(а): > > At Wed, 29 Aug 2018 10:42:59 -0300, Andrey Borodin > wrote in <6fbe12b2-4f59-4db9-bde9-62c880118...@yandex-team.ru> >> >> We are passing freespace everywhere. Also, we pass GistInsertS

B-tree cache prefetches

lect (random()*100)::int from generate_series(1,1e7); it brings something like 2-4% of performance improvement on my laptop. Is there a reason why we do not use __builtin_prefetch? Have anyone tried to use cache prefetching? Best regards, Andrey Borodin.

Re: A strange GiST error message or fillfactor of GiST build

ome > experiments first, and then propose a patch. FWIW fillfactor can be a cheap emulator for intrapage indexing, when you have like a lot of RAM. Though I didn't tested that. Also I believe proper intrapage indexing is better :) Best regards, Andrey Borodin.

Re: A strange GiST error message or fillfactor of GiST build

> 5 сент. 2018 г., в 13:29, Kyotaro HORIGUCHI > написал(а): > > We don't preserve it for Andrey's use case. Just my 2 cents: that was a hacky use case for development reasons. I think that removing fillfactor is good idea and your latest patch looks good from my POV.

<    1   2   3   4   5   6   7   8   9   >