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
ance function is lossy");
Some small typos:
usefull -> useful
nearest-neighbour -> nearest-neighbor (or do we use e.g. "colour"?)
Best regards, Andrey Borodin.
.
"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.
stack and queue?
Best regards, Andrey Borodin.
[0] https://commitfest.postgresql.org/14/1215/
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.
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
> 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
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.
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
> 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
> 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
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.
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
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.
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
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.
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.
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
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
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
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.
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
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
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
lease rebase it one more time?
Here's rebased version. Thanks!
Best regards, Andrey Borodin.
0001-Covering-GiST-v5.patch
Description: Binary data
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
о
быть суперпользователем"? 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.
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
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.
avior?
It seems to me that locking order must be left->deleted->parent.
Best regards, Andrey Borodin.
> 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
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
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
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
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.
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). */
>
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
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
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.
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.
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.
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.
e is done wrong"
due to really bad performance.
Best regards, Andrey Borodin.
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.
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
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" :
>>
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:
>>
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.
part, it is MR
subsystem.
Best regards, Andrey Borodin.
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
e very synthetic. Do we have a natural way to demonstrate a
performance improvement? Like reference pile of bytes...
Best regards, Andrey Borodin.
^ 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.
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
AL-G is hosted under PostgreSQL umbrella.
Thanks!
Best regards, Andrey Borodin.
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
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.
> 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
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.
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
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
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
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.
> 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
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
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.
ly, tuples should not be bigger than half of
usable page space.
Best regards, Andrey Borodin.
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.
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
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,
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.
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.
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;
> +
-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.
> 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
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.
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
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
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.
be change from "dbuffer->pbuffer->lbuffer" to "lbuffer->dbuffer->pbuffer" . Is this right?This looks correct to me.Best regards, Andrey Borodin.
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'
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
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.
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
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>
>>
>>
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
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
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.
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
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
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.
de(ERRCODE_ARRAY_ELEMENT_ERROR),
+errmsg("A cube cannot have more than %d
dimensions.",
+ CUBE_MAX_DIM)));
dur = ARRPTR(ur);
Best regards, Andrey Borodin.
> 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
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.
> 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:
thod will stay safe forever.
But now it is.
Best regards, Andrey Borodin.
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.
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
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.
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.
> 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.
101 - 200 of 895 matches
Mail list logo