| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Sam Wong <sam(at)hellosam(dot)net>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Slow plan for MAX/MIN or LIMIT 1? |
| Date: | 2013-09-25 17:05:09 |
| Message-ID: | CAGTBQpa=5xrwb00gHmsxEzt6bTktPe5sguK+9yuQccGPUfBnCQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Sep 25, 2013 at 12:54 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> I was thinking an index over:
>>
>> (event, date_trunc('day', insert_time), log_id)
>>
>> And the query like
>>
>> SELECT min(log_id) FROM event_log
>> WHERE event='S-Create' AND
>> date_trunc('day',insert_time) = '2013-09-15'
>>
>>
>> That's a regular simple range scan over the index.
>
> *) date_trunc has same problems as ::date: it is stable expression
> only for timestamptz. also, the index will be bigger since you're
> still indexing timestamp
Ah, yes, good point.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-09-25 17:29:15 | Re: Why is n_distinct always -1 for range types? |
| Previous Message | Sam Wong | 2013-09-25 16:42:31 | Re: Slow plan for MAX/MIN or LIMIT 1? |