From: | Jason Dusek <jason(dot)dusek(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Rules, Windows and ORDER BY |
Date: | 2012-08-24 09:32:32 |
Message-ID: | CAO3NbwNYdA0+hOsze5AjdN6CmmkWG97EXRkauNmmoQs+yrvbcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2012/8/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Jason Dusek <jason(dot)dusek(at)gmail(dot)com> writes:
>> I have a simple table of keys and values which periodically
>> receives updated values. It's desirable to keep older values
>> but, most of the time, we query only for the latest value of a
>> particular key.
>
>> CREATE TABLE kv
>> ( k bytea NOT NULL,
>> at timestamptz NOT NULL,
>> realm bytea NOT NULL,
>> v bytea NOT NULL );
>> CREATE INDEX ON kv USING hash(k);
>> CREATE INDEX ON kv (t);
>> CREATE INDEX ON kv USING hash(realm);
>
>> SELECT * FROM kv WHERE k = $1 AND realm = $2 ORDER BY at DESC LIMIT 1;
>
> If you want to make that fast, an index on (k,realm,at) would
> help. Those indexes that you did create are next to useless
> for this, and furthermore hash indexes are quite unsafe for
> production.
Thanks for pointing out the unsafety of hash indexes. I think I
got in the habit of using them for a project with large,
temporary data sets.
Why are the individual indices not useful? The tests that the
query does -- equality on key and realm and ordering on at --
are each supported by indices. Does it have to do with the cost
of loading the three indices?
--
Jason Dusek
pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
From | Date | Subject | |
---|---|---|---|
Next Message | SUNDAY A. OLUTAYO | 2012-08-24 10:10:02 | Re: Windows SIngle Sign On - LINUX Server |
Previous Message | Pavel Stehule | 2012-08-24 04:34:04 | Re: FETCH in subqueries or CTEs |