Re: Slow query with big tables

From: Craig James <cjames(at)emolecules(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Mike Sofen <msofen(at)runbox(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Slow query with big tables
Date: 2016-08-27 14:13:00
Message-ID: CAFwQ8rcGGeVk0Gayz1QEP+VMp8AQi8O-f=OtbtR5T2OXVp8iiQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Aug 26, 2016 at 9:11 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 8/26/16 3:26 PM, Mike Sofen wrote:
>
>> Is there way to keep query time constant as the database size grows.
>>
>
> No. More data == more time. Unless you find a way to break the laws of
> physics.
>

Straight hash-table indexes (which Postgres doesn't use) have O(1) access
time. The amount of data has no effect on the access time. Postgres uses
B-trees which have O(logN) performance. There is no "law of physics" that
says Postgres couldn't employ pure hash indexes.

Craig

> Should I use partitioning or partial indexes?
>>
>
> Neither technique is a magic bullet. I doubt either would help here.
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
> 855-TREBLE2 (855-873-2532) mobile: 512-569-9461
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

--
---------------------------------
Craig A. James
Chief Technology Officer
eMolecules, Inc.
---------------------------------

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2016-08-27 16:36:56 Re: Slow query with big tables
Previous Message Pavel Stehule 2016-08-27 04:55:48 Re: Slow query with big tables