Re: Cluster table based on grand parent?

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Cluster table based on grand parent?
Date: 2023-03-28 16:49:40
Message-ID: add42d7a-3a90-73d8-485e-fd8eb9410fde@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 3/28/23 10:28, Dominique Devienne wrote:
> On Tue, Mar 28, 2023 at 6:06 PM Ron <ronljohnsonjr(at)gmail(dot)com> wrote:
>
> You can only get from parent to grandchild via//child.id
> <http://child.id> to grandchild.parent, so why not cluster
> grandchild on grandchild.parent?
>
>
> Hi. I don't understand your question. Yes, of course, if I want all
> grand-children of a given parent, I'll do for example:
>
> select p.id <http://p.id>, c.id <http://c.id>, c.name <http://c.name>,
> gc.*
>   from  grandchild gc
>    join child c on gc.parent = c.id <http://c.id>
>    join parent p on c.parent = p.id <http://p.id>
> where p.name <http://p.name> = $1
>
> But w/o clustering on a denormalized grandchild.grandparent FK column,
> as Peter showed,
> and cluster only on grandchild.parent, that's not going to access a
> mostly continuous range
> of pages to fetch those all grandchild rows for that one parent. But
> probably 10 to 50 "row-clusters",
> given the fan-out I mentioned earlier at the child-table level. Or am
> I missing something?
Are you using HDD (spinning) or SSD discs?
Is you world strictly three levels: grand,parent,child?
What tests have you done so far to compare clustered to non-clustered?

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ron 2023-03-28 17:00:21 Re: Cluster table based on grand parent?
Previous Message Maciek Sakrejda 2023-03-28 16:45:48 Re: Using CTID system column as a "temporary" primary key