Florian Weimer wrote:
> Kevin Grittner:
>> Well, unless you use timestamp WITH time zone, you might not be
>> able to do that at all. There are very few places where timestamp
>> WITHOUT time zone actually makes sense.
>
> I don't think PostgreSQL keeps track of actual time zone values,
True --
* Kevin Grittner:
> Dave Crooke wrote:
>
>> create table data
>>(id_key int,
>> time_stamp timestamp without time zone,
>> value double precision);
>>
>> create unique index data_idx on data (id_key, time_stamp);
>
>> I need to find the most recent value for each distinct value o
Unfortunately, I'm running 8.3.3 and to my knowledge the windowing stuff
wasn't added til 8.4.
Dave
On Feb 26, 2011 2:06 PM, "Josh Berkus" wrote:
> Dave,
>
> Why not test the windowing version I posted?
>
> --
> -- Josh Berkus
> PostgreSQL Experts Inc.
> http://www.pgexperts.com
On 2/25/11 5:31 AM, Sam Wong wrote:
> I found that "LIKE", "= ANY (...)", "LIKE .. OR LIKE .." against a text
> field used the index correctly, but not "LIKE ANY (...)". Would that be a
> bug?
No, it would be a TODO. This is a known limitation; it needs some
clever code to make it work, and nobod
Dave,
Why not test the windowing version I posted?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgr
Bhakti Ghatkar writes:
> We were running full vacuum on DB when we encountered the error below;
> INFO: vacuuming "pg_catalog.pg_index"
> *vacuumdb: vacuuming of database "rpt_production" failed: ERROR: duplicate
> key value violates unique constraint "pg_index_indexrelid_index"*
> DETAIL: Key
On Fri, Feb 25, 2011 at 1:45 PM, Dave Crooke wrote:
> Hi Dave
>
> Yes, 100% the best solution I did the same thing a while back, I just
> have a separate copy of the data in a "latest" table and the Java code just
> runs a second SQL statement to update it when writing a new record (I've
> n
