Re: Efficient sorting the results of a join, without denormalization

From: Francisco Olarte <folarte(at)peoplecall(dot)com>
To: "Glen M(dot) Witherington" <glen(at)fea(dot)st>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Efficient sorting the results of a join, without denormalization
Date: 2015-06-01 10:27:52
Message-ID: CA+bJJbwte8NiKQU_reXYgWMR-bnJZmRZsCz+hcSokerPq7+8ug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Glen:

On Mon, Jun 1, 2015 at 1:16 AM, Glen M. Witherington <glen(at)fea(dot)st> wrote:

> Thanks Francisco, that makes sense. I've started moving my code to that,
> and it eliminates all the performance issues I had.

Happty to hear it. Seems you have a kind of speed-size trade off. If
you can solve it while preserving integrity, great for you.

> I guess I was really hoping there would exist some sort of "dereference"
> option when indexing, so I could dereference a foreign key, and then
> index on a attribute of that row. E.g. So I could have created an index
> such as:
> deref(deref(mail.folder_id).user_id, created_at)

That is difficult, as it would need a way to force mail.folder.user_id
to be a constant or have a lot of rules/triggers ( manual, automatic
or just plain magic ) to update your indexes. On this cases composite
keys let you use composite indexes to accelerate your queries while
preserving normalization, if you can afford them they are nice. The
big problem comes many times if you try to mix them with ORMs and
similar.

Francisco Olarte.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message ben.play 2015-06-01 12:57:59 Re: My index doesn't write anymore but read
Previous Message Andres Freund 2015-06-01 08:58:09 Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1