Hi Rob:
On Tue, Aug 23, 2016 at 4:52 PM, Rob Sargent wrote:
> By 'this' I was referring to the optimizations mentioned, and am wondering
> if this holds true under user load.
For that you'll have to refer to the source, or ask someone more
versed in pg source arcanes.
> Much magic can happen in
On 08/23/2016 08:34 AM, Francisco Olarte wrote:
On Tue, Aug 23, 2016 at 4:28 PM, Rob Sargent wrote:
On 08/23/2016 07:44 AM, Francisco Olarte wrote:
On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
I am just surprised by the order of magnitude in the difference though. 2
and 27 minutes that's
On Tue, Aug 23, 2016 at 4:28 PM, Rob Sargent wrote:
> On 08/23/2016 07:44 AM, Francisco Olarte wrote:
>> On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
>>> I am just surprised by the order of magnitude in the difference though. 2
>>> and 27 minutes that's the huge difference... I did another, sim
On 08/23/2016 07:44 AM, Francisco Olarte wrote:
Hi pinker:
On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
I am just surprised by the order of magnitude in the difference though. 2
and 27 minutes that's the huge difference... I did another, simplified test,
to make sure there is no duplicates
Hi pinker:
On Tue, Aug 23, 2016 at 2:26 PM, pinker wrote:
> I am just surprised by the order of magnitude in the difference though. 2
> and 27 minutes that's the huge difference... I did another, simplified test,
> to make sure there is no duplicates and the only difference between both
> sets is
Francisco Olarte wrote
> It's already been told that btrees work that way, if you find itstrange
> read a bit about them, this is completely normal, but ...
I am just surprised by the order of magnitude in the difference though. 2
and 27 minutes that's the huge difference...I did another, simplifi
On Fri, Aug 19, 2016 at 3:20 PM, Daniel Verite wrote:
> There's a simple technique that works on top of a Feistel network,
> called the cycle-walking cipher. Described for instance at:
> http://web.cs.ucdavis.edu/~rogaway/papers/subset.pdf
> I'm using the opportunity to add a wiki page:
> https://
Francisco Olarte wrote:
> I think there are some pseudo-random number generators which
> can be made to work with any range, but do not recall which ones right
> now.
There's a simple technique that works on top of a Feistel network,
called the cycle-walking cipher. Described for instance
Daniel:
On Thu, Aug 18, 2016 at 5:24 PM, Daniel Verite wrote:
>> unless you know of an easy way to generate a random permutation on the
>> fly without using a lot of memory, I do not.
> It could be done by encrypting the stream.
> For 32 bits integers:
> https://wiki.postgresql.org/wiki/Skip32
> F
Francisco Olarte wrote:
> unless you know of an easy way to generate a random permutation on the
> fly without using a lot of memory, I do not.
It could be done by encrypting the stream.
For 32 bits integers:
https://wiki.postgresql.org/wiki/Skip32
For 64 bits integers:
https://wiki.pos
Hi:
On Thu, Aug 18, 2016 at 1:32 PM, pinker wrote:
...
> create table t01 (id bigint);
> create index i01 on t01(id);
> insert into t01 SELECT s from generate_series(1,1000) as s;
>
> and random values:
> create table t02 (id bigint);
> create index i02 on t02(id);
> insert into t02 SELECT ra
W dniu 2016-08-18 14:19:25 użytkownik Ilya Kazakevich
napisał:
> >Thank you. So if that is the reason changing the fillfactor parameter should
> >help?
>
> Fillfactor is not about rebalancing, but about page split. If you have many
> insertions you may decrease fillfactor to minimize page sp
>Thank you. So if that is the reason changing the fillfactor parameter should
>help?
Fillfactor is not about rebalancing, but about page split. If you have many
insertions you may decrease fillfactor to minimize page splits, but I am not
sure it will help in your case. But you should try)
Bett
W dniu 2016-08-18 14:00:31 użytkownik Ilya Kazakevich
napisał:
> Hi,
>
> >What's the reason that postgres needs more index pages to store random
> >data
> >than sequential ones?
>
> I assume that is because B-Tree is self-balanced tree, so it needs to be
> rebalanced after each insertion.
>
Hi,
>What's the reason that postgres needs more index pages to store random
>data
>than sequential ones?
I assume that is because B-Tree is self-balanced tree, so it needs to be
rebalanced after each insertion.
Random insertions may go to the head of index where no space left leading to
huge dat
Hi!
After doing a quick test:
with sequential values:
create table t01 (id bigint);
create index i01 on t01(id);
insert into t01 SELECT s from generate_series(1,1000) as s;
and random values:
create table t02 (id bigint);
create index i02 on t02(id);
insert into t02 SELECT random()*100 from ge
16 matches
Mail list logo
