On Fri, Oct 27, 2017 at 5:36 PM, Alvaro Herrera
wrote:
> Amit Kapila wrote:
>
>> You might want to give a try with the hash index if you are planning
>> to use PG10 and your queries involve equality operations.
>
> So, btree indexes on monotonically increasing sequences don't write tons
> of full
Amit Kapila wrote:
> You might want to give a try with the hash index if you are planning
> to use PG10 and your queries involve equality operations.
So, btree indexes on monotonically increasing sequences don't write tons
of full page writes because typically the same page is touched many
times
On Fri, Oct 27, 2017 at 11:26 AM, sanyam jain wrote:
> Hi,
>
> I was reading the blog
> https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes .
>
> My queries:
>
> How randomness of UUID will likely to create new leaf page in btree index?
> In my understanding as the size of UUID is 128 b
On 10/27/2017 07:56 AM, sanyam jain wrote:
> Hi,
>
> I was reading the
> blog https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes .
>
For the record, I assume you're referring to this part:
With BIGSERIAL new values are sequential, and so get inserted to the
same leaf pages
Hi,
I was reading the blog
https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes .
My queries:
How randomness of UUID will likely to create new leaf page in btree index?
In my understanding as the size of UUID is 128 bits i.e. twice of BIGSERIAL ,
more number of pages will be required
