On Thu, Mar 24, 2016 at 7:12 PM, Peter Geoghegan wrote:
> On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote:
>> I really like this idea, and the performance results seem impressive,
>> but I think we should push this out to 9.7. A btree patch that didn't
>> have WAL support until two and a half
On Wed, Aug 17, 2016 at 10:40 AM, Tom Lane wrote:
> Oskari Saarenmaa writes:
>> On my laptop a simple pgbench run (scale 100, 15 minutes) shows a 1.5%
>> performance improvement.
>
> I would have hoped for a lot better result before anyone would propose
> that we should deal with all the portabil
On Thu, Aug 18, 2016 at 5:05 PM, Robert Haas wrote:
> On Wed, Aug 17, 2016 at 10:54 PM, Claudio Freire
> wrote:
>> The attached patch tries to maintain the initial status of B-Tree
>> indexes, which are created with equal-key runs in physical order,
>> during the whole
On Thu, Aug 18, 2016 at 6:04 PM, Kevin Grittner wrote:
> On Thu, Aug 18, 2016 at 3:41 PM, Claudio Freire
> wrote:
>
>> It also makes index scans of the form
>>
>> SELECT * FROM t WHERE some_col = some_const;
>>
>> Scan the heap in sequential order, even
On Thu, Aug 18, 2016 at 6:15 PM, Peter Geoghegan wrote:
> On Thu, Aug 18, 2016 at 1:41 PM, Claudio Freire
> wrote:
>> In fact, that's why non-leaf index tuples need a different format,
>> because while leaf index tuples contain the heap pointer already,
>> n
On Thu, Aug 18, 2016 at 6:27 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Thu, Aug 18, 2016 at 6:04 PM, Kevin Grittner wrote:
>>> Speaking of performance side effects, does this avoid O(N^2)
>>> performance on index tuple insertion with duplicate values, for
On Thu, Aug 18, 2016 at 6:38 PM, Peter Geoghegan wrote:
> On Thu, Aug 18, 2016 at 2:26 PM, Claudio Freire
> wrote:
>> I see that. I could try to measure average depth to measure the impact
>> this had on fan-in.
>>
>> While it should cut it in half for narrow in
On Thu, Aug 18, 2016 at 6:26 PM, Claudio Freire wrote:
> On Thu, Aug 18, 2016 at 6:15 PM, Peter Geoghegan wrote:
>> On Thu, Aug 18, 2016 at 1:41 PM, Claudio Freire
>> wrote:
>>> In fact, that's why non-leaf index tuples need a different format,
>>> becau
On Sat, Aug 20, 2016 at 1:05 AM, Amit Kapila wrote:
> On Thu, Aug 18, 2016 at 8:24 AM, Claudio Freire
> wrote:
>>
>> A couple of points make me uneasy about this patch, yet I can think of
>> no better alternative, so I seek feedback:
>>
>> - introducin
On Sat, Aug 20, 2016 at 1:53 AM, Claudio Freire wrote:
> All uniqueness checks will try to read-lock nbuf
> unless the uniqueness check for that insertion is done.
That should read "all uniqueness checks will try to read-lock the buf
unless the uniqueness check for that insert
On Sat, Aug 20, 2016 at 4:27 AM, Amit Kapila wrote:
>> All uniqueness checks will find the same "nbuf" (read-locked), which
>> is the first one that matches the key.
>>
>> They could have different "buf" buffers (the write-locked) one. But
>> since read locks cannot be held while a write-lock is h
On Tue, Aug 23, 2016 at 8:02 AM, Masahiko Sawada wrote:
>
> 2. Vacuum table and index (after 1 transaction executed)
> 1 worker : 12 sec
> 2 workers : 49 sec
> 3 workers : 54 sec
> 4 workers : 53 sec
>
> As a result of my test, since multiple process could frequently try to
> acquire
On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
wrote:
> On 08/22/2016 10:32 PM, Robert Haas wrote:
>>
>>
>> ...
>>
>> 1. The number of tables for which we would need to add a duplicate,
>> unlogged table is formidable. You need pg_attribute, pg_attrdef,
>> pg_constraint, pg_description, pg_type, p
On Tue, Aug 23, 2016 at 7:20 PM, Andres Freund wrote:
>> Wouldn't more aggressive vacuuming of catalog tables fix the bloat?
>
> Not really in my experience, at least not without more drastic vacuum
> changes. The issue is that if you have a single "long running"
> transaction (in some workloads t
On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra
wrote:
>>> Could someone please explain how the unlogged tables are supposed to fix
>>> the
>>> catalog bloat problem, as stated in the initial patch submission? We'd
>>> still
>>> need to insert/delete the catalog rows when creating/dropping the
>>> t
On Tue, Aug 23, 2016 at 8:50 PM, Greg Stark wrote:
> On Tue, Aug 23, 2016 at 4:15 PM, Aleksander Alekseev
> wrote:
>> Frankly I have much more faith in Tom's idea of using virtual part of the
>> catalog for all temporary tables, i.e turning all temporary tables into
>> "fast" temporary tables. In
On Tue, Aug 23, 2016 at 9:12 PM, Tomas Vondra
wrote:
> On 08/24/2016 12:38 AM, Claudio Freire wrote:
>>
>> On Tue, Aug 23, 2016 at 7:25 PM, Tomas Vondra
>> wrote:
>>>>>
>>>>> Could someone please explain how the unlogged tables are supposed to
On Wed, Aug 24, 2016 at 2:04 AM, Alvaro Herrera
wrote:
> Claudio Freire wrote:
>
>> After looking at it from a birdseye view, I agree it's conceptually
>> complex (reading HeapTupleSatisfiesSelf already makes one dizzy).
>>
>> But other than that, the implement
On Wed, Aug 24, 2016 at 10:31 PM, Robert Haas wrote:
> 1. Transaction rates are vastly higher these days. In 1999, I think
> we were still limited to ~2^32 transactions during the entire lifetime
> of the server; transaction ID wraparound hadn't been invented yet.[1]
> Today, some installations d
On Thu, Aug 25, 2016 at 12:21 PM, Simon Riggs wrote:
> On 25 August 2016 at 02:31, Robert Haas wrote:
>
>> Furthermore, there is an enforced, synchronous fsync at the end of
>> every segment, which actually does hurt performance on write-heavy
>> workloads.[2] Of course, if that were the only rea
On Wed, Aug 31, 2016 at 1:45 PM, Pavan Deolasee
wrote:
> We discussed a few ideas to address the "Duplicate Scan" problem. For
> example, we can teach Index AMs to discard any duplicate (key, CTID) insert
> requests. Or we could guarantee uniqueness by either only allowing updates
> in one lexica
work fine.
From feddd4f58c30ca6a446ce0eed343f2562030f0e5 Mon Sep 17 00:00:00 2001
From: Claudio Freire
Date: Fri, 2 Sep 2016 23:21:01 -0300
Subject: [PATCH 1/2] Vacuum: allow using more than 1GB work mem
Turns the palloc for dead_tuples into a huge allocation to allow
using more than 1GB worth of dead_tuples, sav
On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs wrote:
> On 3 September 2016 at 04:25, Claudio Freire wrote:
>> The patch also makes vacuum free the dead_tuples before starting
>> truncation. It didn't seem necessary to hold onto it beyond that
>> point, and it might h
On Mon, Sep 5, 2016 at 11:50 AM, Claudio Freire wrote:
> On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs wrote:
>> On 3 September 2016 at 04:25, Claudio Freire wrote:
>>> The patch also makes vacuum free the dead_tuples before starting
>>> truncation. It didn't seem
On Mon, Sep 5, 2016 at 5:36 PM, Simon Riggs wrote:
> On 5 September 2016 at 15:50, Claudio Freire wrote:
>> On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs wrote:
>>> On 3 September 2016 at 04:25, Claudio Freire wrote:
>>>> The patch also makes vacuum free t
the OS ASAP.
AFAIK, except on debug builds where it has to memset the whole thing,
the cost is constant (unrelated to the allocated block size), so it
should be rather small in this context.
On Tue, Sep 6, 2016 at 1:42 PM, Robert Haas wrote:
> On Sat, Sep 3, 2016 at 8:55 AM, Claudio F
On Tue, Sep 6, 2016 at 2:08 PM, Tom Lane wrote:
>> The not-quoting-if-not-needed doesn't appear to do anything useful for me:
>> 'pg-install/bin/pg_ctl' -D 'pg-install/var/data' -l logfile start
>
> Dash is considered a character that needs quoting. It might be possible
> to avoid that if we
On Tue, Sep 6, 2016 at 2:39 PM, Robert Haas wrote:
>> I could attempt that, but I don't see the difference between
>> vacuum and create index in this case. Both could allocate a huge chunk
>> of the virtual address space if maintainance work mem says so, both
>> proportional to the size of the tab
On Tue, Sep 6, 2016 at 3:11 PM, Tom Lane wrote:
> We could get around (1) by something like Robert's idea of segmented
> allocation, but TBH I've seen nothing on this thread to make me think
> it's necessary or would even result in any performance improvement
> at all. The bigger we make that arr
On Tue, Sep 6, 2016 at 3:45 AM, Simon Riggs wrote:
> On 5 September 2016 at 21:58, Claudio Freire wrote:
>
>>>>> How long does that part ever take? Is there any substantial gain from
>>>>> this?
>
>> Btw, without a further patch to prefetch pages
On Mon, Aug 15, 2016 at 9:33 PM, Peter Geoghegan wrote:
> The patch is intended to be applied on top of parallel B-Tree patches
> 0001-* and 0002-* [1]. I happened to test it with parallelism, but
> these are all independently useful, and will be entered as a separate
> CF entry (perhaps better to
On Tue, Sep 6, 2016 at 8:28 PM, Peter Geoghegan wrote:
> On Tue, Sep 6, 2016 at 12:57 PM, Claudio Freire
> wrote:
>> Patch lacks any new tests, but the changed code paths seem covered
>> sufficiently by existing tests. A little bit of fuzzing on the patch
>> itself,
On Tue, Sep 6, 2016 at 9:19 PM, Peter Geoghegan wrote:
> On Tue, Sep 6, 2016 at 4:55 PM, Claudio Freire wrote:
>> I noticed, but here n = state->memtupcount
>>
>> + Assert(memtuples[0].tupindex == newtup->tupindex);
>> +
>> + CHECK_FOR_
On Wed, Sep 7, 2016 at 12:12 PM, Greg Stark wrote:
> On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs wrote:
>> On 6 September 2016 at 19:59, Tom Lane wrote:
>>
>>> The idea of looking to the stats to *guess* about how many tuples are
>>> removable doesn't seem bad at all. But imagining that that's
On Thu, Sep 8, 2016 at 11:54 AM, Pavan Deolasee
wrote:
> For example, for a table with 60 bytes wide tuple (including 24 byte
> header), each page can approximately have 8192/60 = 136 tuples. Say we
> provision for 136*2 = 272 bits per page i.e. 34 bytes per page for the
> bitmap. First 272 offset
we say over here, rather
badly translated, not a turkey's boogers (meaning "nice!")
On Tue, Sep 6, 2016 at 9:50 PM, Claudio Freire wrote:
> On Tue, Sep 6, 2016 at 9:19 PM, Peter Geoghegan wrote:
>> On Tue, Sep 6, 2016 at 4:55 PM, Claudio Freire
>>
On Thu, Sep 8, 2016 at 2:13 PM, Peter Geoghegan wrote:
> On Thu, Sep 8, 2016 at 8:53 AM, Claudio Freire wrote:
>> setup:
>>
>> create table lotsofitext(i text, j text, w text, z integer, z2 bigint);
>> insert into lotsofitext select cast(rand
On Thu, Sep 8, 2016 at 4:20 PM, Peter Geoghegan wrote:
> On Thu, Sep 8, 2016 at 10:40 AM, Tom Lane wrote:
>>> On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
I still think tuplesort_heap_siftup is a confusing name, although I'm not
sure that Peter's "compact" is much better.
On Thu, Sep 8, 2016 at 2:19 PM, Peter Geoghegan wrote:
>> Peter, looking at your "displace" patch in this light, I think
>> tuplesort_heap_root_displace() and tuplesort_heap_delete_top() (as I'm
>> calling it now), should share a common subroutine. Displace replaces the top
>> node with the new no
...
On Fri, Sep 9, 2016 at 9:22 PM, Claudio Freire wrote:
> Since it is true that doing so would make it impossible to keep the
> asserts about tupindex in tuplesort_heap_root_displace, I guess it
> depends on how useful those asserts are (ie: how likely it is that
> those conditi
On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote:
>
> Claudio, if you could also repeat the tests you ran on Peter's patch set on
> the other thread, with these patches, that'd be nice. These patches are
> effectively a replacement for
> 0002-Use-tuplesort-batch-memory-for-randomAccess-sor
On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire wrote:
> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote:
>>
>> Claudio, if you could also repeat the tests you ran on Peter's patch set on
>> the other thread, with these patches, that'd be nice. The
On Sun, Sep 11, 2016 at 12:47 PM, Heikki Linnakangas wrote:
> Here's a new version of these patches, rebased over current master. I
> squashed the two patches into one, there's not much point to keep them
> separate.
I don't know what was up with the other ones, but this one works fine.
Benchma
On Tue, Sep 13, 2016 at 3:51 PM, Robert Haas wrote:
> On Fri, Sep 9, 2016 at 3:04 AM, Masahiko Sawada wrote:
>> Attached PoC patch changes the representation of dead tuple locations
>> to the hashmap having tuple bitmap.
>> The one hashmap entry consists of the block number and the TID bitmap
>>
On Tue, Sep 13, 2016 at 4:06 PM, Robert Haas wrote:
> On Tue, Sep 13, 2016 at 2:59 PM, Claudio Freire
> wrote:
>> I've finished writing that patch, I'm in the process of testing its CPU
>> impact.
>>
>> First test seemed to hint at a 40% increase i
On Wed, Sep 14, 2016 at 12:17 PM, Robert Haas wrote:
>
> I am kind of doubtful about this whole line of investigation because
> we're basically trying pretty hard to fix something that I'm not sure
> is broken.I do agree that, all other things being equal, the TID
> lookups will probably be fa
On Wed, Sep 14, 2016 at 12:17 PM, Robert Haas wrote:
> For instance, one idea to grow memory usage incrementally would be to
> store dead tuple information separately for each 1GB segment of the
> relation. So we have an array of dead-tuple-representation objects,
> one for every 1GB of the relat
ry files.
One would not expect "CREATE INDEX" to succeed when space is tight,
but VACUUM is quite the opposite.
Still, temporary storage could be used if available, and gracefully
fall back to some other technique (like not using bitmaps) when not.
Not sure it's worth the troubl
On Thu, Sep 15, 2016 at 3:48 PM, Tomas Vondra
wrote:
> For example, we always allocate the TID array as large as we can fit into
> m_w_m, but maybe we don't need to wait with switching to the bitmap until
> filling the whole array - we could wait as long as the bitmap fits into the
> remaining par
On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire wrote:
> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote:
>>
>> Claudio, if you could also repeat the tests you ran on Peter's patch set on
>> the other thread, with these patches, that'd be nice. The
On Tue, Sep 20, 2016 at 3:34 PM, Claudio Freire wrote:
> On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire wrote:
>> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote:
>>>
>>> Claudio, if you could also repeat the tests you ran on Peter's patch set on
On Thu, Sep 22, 2016 at 4:17 AM, Heikki Linnakangas wrote:
> On 09/22/2016 03:40 AM, Claudio Freire wrote:
>>
>> On Tue, Sep 20, 2016 at 3:34 PM, Claudio Freire
>> wrote:
>>>
>>> The results seem all over the map. Some regressions seem significant
>>
On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
> Sokolov Yura writes:
>> [ 0001-Improve-compactify_tuples.patch, v5 or thereabouts ]
>
> I started to review this patch. I spent a fair amount of time on
> beautifying the code, because I found it rather ugly and drastically
> undercommented. On
On Fri, Nov 3, 2017 at 4:30 PM, Tom Lane wrote:
> Claudio Freire writes:
>> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane wrote:
>>> BTW, the originally given test case shows no measurable improvement
>>> on my box.
>
>> I did manage to reproduce the original t
_i < _n; _i += 1) \
>>
>> or maybe just _i++.
>
>
> Shame on me :-(
> I've wrote shell sort several times, so I forgot to recheck myself once
> again.
> And looks like best gap sequence from wikipedia is really best
> ( {301, 132, 57, 23, 10 , 4} in my nota
On Mon, Nov 6, 2017 at 11:50 AM, Юрий Соколов wrote:
>> Maybe leave a fallback to qsort if some corner case produces big buckets?
>
> For 8kb pages, each bucket is per 32 bytes. So, for heap pages it is at
> most 1 heap-tuple per bucket, and for index pages it is at most 2 index
> tuples per bucke
On Mon, Nov 6, 2017 at 6:58 PM, Юрий Соколов wrote:
>
> 2017-11-06 17:55 GMT+03:00 Claudio Freire :
>>
>> On Mon, Nov 6, 2017 at 11:50 AM, Юрий Соколов
>> wrote:
>> >> Maybe leave a fallback to qsort if some corner case produces big
>> >> buckets
On Mon, Nov 6, 2017 at 9:08 PM, Юрий Соколов wrote:
> 2017-11-07 1:14 GMT+03:00 Claudio Freire :
>>
>> I haven't seen this trick used in postgres, nor do I know whether it
>> would be well received, so this is more like throwing an idea to see
>> if it sticks...
&g
On Tue, Nov 7, 2017 at 11:42 AM, Юрий Соколов wrote:
>
>
> 2017-11-07 17:15 GMT+03:00 Claudio Freire :
>> Aside from requiring all that include magic, if you place specialized
>> sort functions in a reusable header, using it is as simple as
>> including the type-specif
On Wed, Nov 8, 2017 at 12:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 7, 2017 at 4:39 PM, Tom Lane wrote:
>>> What I'm getting from the standard pgbench measurements, on both machines,
>>> is that this patch might be a couple percent slower than HEAD, but that is
>>> barely above
On Tue, Oct 4, 2016 at 7:47 AM, Heikki Linnakangas wrote:
> 1. The first patch changes the way we store the logical tapes on disk.
> Instead of using indirect blocks, HFS style, the blocks form a linked list.
> Each block has a trailer, with the block numbers of the previous and next
> block of th
On Sun, Sep 11, 2016 at 1:20 PM, Tom Lane wrote:
> Michael Malis writes:
>> As I understand it, a merge join will currently read all tuples from both
>> subqueries (besides early termination). I believe it should be possible to
>> take advantages of the indexes on one or both of the tables being
On Tue, Oct 18, 2016 at 3:28 PM, Alvaro Herrera
wrote:
> I propose we introduce the concept of "indirect indexes". I have a toy
> implementation and before I go further with it, I'd like this assembly's
> input on the general direction.
>
> Indirect indexes are similar to regular indexes, except
On Tue, Oct 18, 2016 at 5:48 PM, Simon Riggs wrote:
> On 18 October 2016 at 22:04, Claudio Freire wrote:
>> On Tue, Oct 18, 2016 at 3:28 PM, Alvaro Herrera
>> wrote:
>>> I propose we introduce the concept of "indirect indexes". I have a toy
>>> imp
On Wed, Oct 19, 2016 at 10:21 AM, Simon Riggs wrote:
>> Simon objected that putting the PK
>> into the index tuple would disable HOT, but I don't think that's a
>> valid objection.
>
> Just to be clear, that's not what I objected to. Claudio appeared to
> be suggesting that an indirect index is th
On Wed, Oct 19, 2016 at 2:04 PM, Bruce Momjian wrote:
>> What we should ask is what is the difference between indirect indexes
>> and WARM and to what extent they overlap.
>>
>> My current understanding is that WARM won't help you if you update
>> parts of a JSON document and/or use GIN indexes, b
On Thu, Oct 20, 2016 at 12:14 PM, Petr Jelinek wrote:
> WARM can do WARM update 50% of time, indirect index can do HOT update
> 100% of time (provided the column is not changed), I don't see why we
> could not have both solutions.
>
> That all being said, it would be interesting to hear Álvaro's t
On Thu, Oct 20, 2016 at 12:30 PM, Pavan Deolasee
wrote:
>
>
> On Thu, Oct 20, 2016 at 8:44 PM, Petr Jelinek wrote:
>>
>>
>>
>> WARM can do WARM update 50% of time, indirect index can do HOT update
>> 100% of time (provided the column is not changed), I don't see why we
>> could not have both solu
On Thu, Oct 20, 2016 at 1:08 PM, Pavan Deolasee
wrote:
> On Thu, Oct 20, 2016 at 9:20 PM, Claudio Freire
> wrote:
>>
>>
>>
>> With indirect indexes, since you don't need to insert a tid, you can
>> just "insert on conflict do nothing" on the i
On Wed, Oct 26, 2016 at 9:33 PM, Peter Geoghegan wrote:
> Besides, parallel CREATE INDEX alone will probably
> be quite effective at speeding up CLUSTER in practice, simply because
> that's often where most wall clock time is spent during a CLUSTER
> operation.
Creating all indexes in parallel co
On Thu, Nov 17, 2016 at 2:34 PM, Masahiko Sawada wrote:
> I glanced at the patches but the both patches don't obey the coding
> style of PostgreSQL.
> Please refer to [1].
>
> [1]
> http://wiki.postgresql.org/wiki/Developer_FAQ#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F.
I t
On Thu, Nov 17, 2016 at 2:51 PM, Claudio Freire wrote:
> On Thu, Nov 17, 2016 at 2:34 PM, Masahiko Sawada
> wrote:
>> I glanced at the patches but the both patches don't obey the coding
>> style of PostgreSQL.
>> Please refer to [1].
>>
>> [1]
>>
On Thu, Nov 17, 2016 at 6:34 PM, Robert Haas wrote:
> On Thu, Nov 17, 2016 at 1:42 PM, Claudio Freire
> wrote:
>> Attached is patch 0002 with pgindent applied over it
>>
>> I don't think there's any other formatting issue, but feel free to
>> point a fin
On Fri, Nov 18, 2016 at 10:05 PM, Peter Geoghegan wrote:
> On Thu, Aug 18, 2016 at 2:15 PM, Peter Geoghegan wrote:
>> I think that this is a bad idea. We need to implement suffix
>> truncation of internal page index tuples at some point, to make them
>> contain less information from the original
On Fri, Nov 18, 2016 at 11:09 PM, Peter Geoghegan wrote:
> On Fri, Nov 18, 2016 at 5:27 PM, Claudio Freire
> wrote:
>> I've been changing the on-disk format considerably, to one that makes
>> more sense.
>
> I can see how that would be necessary. I'm going
On Mon, Nov 21, 2016 at 2:15 PM, Masahiko Sawada wrote:
> On Fri, Nov 18, 2016 at 6:54 AM, Claudio Freire
> wrote:
>> On Thu, Nov 17, 2016 at 6:34 PM, Robert Haas wrote:
>>> On Thu, Nov 17, 2016 at 1:42 PM, Claudio Freire
>>> wrote:
>>>> Attached i
On Mon, Nov 21, 2016 at 5:42 PM, Peter Geoghegan wrote:
>>> Or, you might want to make
>>> sure that B-Tree tuple insertions still find that "first page" to
>>> check, despite still generally treating heap item pointer as part of
>>> the key proper (in unique indexes, it can still behave like NULL
On Fri, Feb 24, 2017 at 1:24 PM, Robert Haas wrote:
> On Fri, Feb 24, 2017 at 7:29 PM, Kohei KaiGai wrote:
>> This attached patch re-designed the previous v2 according to Robert's
>> comment.
>> All I had to do is putting entrypoint for ForeignScan/CustomScan at
>> ExecShutdownNode,
>> because i
On Thu, Jun 12, 2014 at 1:25 PM, Robert Haas wrote:
>
> It appears that any string starting with the letter "a" will create
> output that begins with 001S00 and the seventh character always
> appears to be 0 or 1:
>
> [rhaas ~]$ ./strxfrm en_US ab ac ad ae af a% a0 "a "
> "ab" -> "001S001T001S
On Tue, Jun 17, 2014 at 1:04 PM, Andres Freund wrote:
> For me minmax indexes are helpful because they allow to generate *small*
> 'coarse' indexes over large volumes of data. From my pov that's possible
> possible because they don't contain item pointers for every contained
> row.
But minmax is
On Tue, Jun 17, 2014 at 8:47 AM, Abhijit Menon-Sen wrote:
> if (compress_backup_block = BACKUP_BLOCK_COMPRESSION_SNAPPY)
You mean == right?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On Thu, Jun 19, 2014 at 10:06 AM, Heikki Linnakangas
wrote:
> On 06/18/2014 06:09 PM, Claudio Freire wrote:
>>
>> On Tue, Jun 17, 2014 at 8:48 PM, Greg Stark wrote:
>>>
>>> An aggregate to generate a min/max "bounding box" from several values
>>
On Thu, Jun 19, 2014 at 2:49 PM, Greg Stark wrote:
> I don't think the threaded implementation on Linux is the one to use
> though. I find this *super* confusing but the kernel definitely
> supports aio syscalls, glibc also has a threaded implementation it
> uses if run on a kernel that doesn't im
On Wed, Jun 18, 2014 at 8:51 AM, Heikki Linnakangas
wrote:
>
> I liked Greg's sketch of what the opclass support functions would be. It
> doesn't seem significantly more complicated than what's in the patch now.
Which was
On Tue, Jun 17, 2014 at 8:48 PM, Greg Stark wrote:
> An aggregate to gen
On Tue, Jun 24, 2014 at 12:08 PM, John Lumby wrote:
>> The question is, if you receive the notification of the I/O completion
>> using a signal or a thread, is it safe to release the lwlock from the
>> signal handler or a separate thread?
>
> In the forthcoming new version of the patch that uses
On Thu, Jun 26, 2014 at 11:18 AM, Kohei KaiGai wrote:
> One thing I concern is, it may conflict with numa-balancing
> features that is supported in the recent Linux kernel; that
> migrates physical pages according to the location of tasks
> which references the page beyond the numa zone.
> # I'm n
On Wed, Jul 9, 2014 at 6:16 PM, Alvaro Herrera wrote:
> Another thing I noticed is that version 8 of the patch blindly believed
> the "pages_per_range" declared in catalogs. This meant that if somebody
> did "alter index foo set pages_per_range=123" the index would
> immediately break (i.e. retur
On Thu, Jul 10, 2014 at 4:20 PM, Alvaro Herrera
wrote:
> Claudio Freire wrote:
>> On Wed, Jul 9, 2014 at 6:16 PM, Alvaro Herrera
>> wrote:
>> > Another thing I noticed is that version 8 of the patch blindly believed
>> > the "pages_per_range" declare
On Fri, Jul 11, 2014 at 3:47 PM, Greg Stark wrote:
> On Fri, Jul 11, 2014 at 6:00 PM, Claudio Freire
> wrote:
>> Marking as read-only is ok, or emitting a NOTICE so that if anyone
>> changes those parameters that change the shape of the index, they know
>> it needs a
On Mon, Jul 14, 2014 at 2:53 PM, Peter Geoghegan wrote:
> My concern is that it won't be worth it to do the extra work,
> particularly given that I already have 8 bytes to work with. Supposing
> I only had 4 bytes to work with (as researchers writing [2] may have
> only had in 1994), that would le
On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
wrote:
> 1. Proposal
> =
> Our proposal is to introduce the concept of a backup profile. The backup
> profile consists of a file with one line per file detailing tablespace,
> path, modification time, size and check
On Fri, Jul 25, 2014 at 3:44 PM, Robert Haas wrote:
> On Fri, Jul 25, 2014 at 2:21 PM, Claudio Freire
> wrote:
>> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
>> wrote:
>>> 1. Proposal
>>> =
>>> Our proposal is
On Fri, Jul 25, 2014 at 7:38 PM, Josh Berkus wrote:
> On 07/25/2014 11:49 AM, Claudio Freire wrote:
>>> I agree with much of that. However, I'd question whether we can
>>> > really seriously expect to rely on file modification times for
>>> > critical da
On Tue, Jul 29, 2014 at 1:24 PM, Marco Nenciarini
wrote:
>> On Fri, Jul 25, 2014 at 10:14 AM, Marco Nenciarini
>> wrote:
>>> 1. Proposal
>>> =
>>> Our proposal is to introduce the concept of a backup profile. The backup
>>> profile consists of a file with one line
On Tue, Jul 29, 2014 at 3:06 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On 25 July 2014 20:47, Tom Lane wrote:
>>> Another idea would be to
>
>> ...persist the optimal dump order in the database.
>
>> That way we can maintain the correct dump order each time we do DDL,
>> which is only a small
On Thu, Jul 31, 2014 at 5:26 AM, desmodemone wrote:
> b) yes the backends need to update the map, but it's in memory, and as I
> show, could be very small if we you chunk of blocks.If we not compress the
> map, I not think could be a bottleneck.
If it's in memory, it's not crash-safe. For somethi
On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila wrote:
>> c) the map is not crash safe by design, because it needs only for
>> incremental backup to track what blocks needs to be backuped, not for
>> consistency or recovery of the whole cluster, so it's not an heavy cost for
>> the whole cluster to m
On Fri, Aug 1, 2014 at 1:43 PM, desmodemone wrote:
>
>
>
> 2014-08-01 18:20 GMT+02:00 Claudio Freire :
>
>> On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila
>> wrote:
>> >> c) the map is not crash safe by design, because it needs only for
>> >>
On Mon, Aug 4, 2014 at 5:15 AM, Gabriele Bartolini
wrote:
>I really like the proposal of working on a block level incremental
> backup feature and the idea of considering LSN. However, I'd suggest
> to see block level as a second step and a goal to keep in mind while
> working on the first ste
On Tue, Aug 5, 2014 at 3:23 PM, Simon Riggs wrote:
> On 4 August 2014 19:30, Claudio Freire wrote:
>> On Mon, Aug 4, 2014 at 5:15 AM, Gabriele Bartolini
>> wrote:
>>>I really like the proposal of working on a block level incremental
>>> backup featur
1 - 100 of 476 matches
Mail list logo
