seful, I think. If your intervals are more complex than date_trunc()
can handle then you'll have to get more creative, but that's the basic
structure -- normalize the primary key, project the sensor data to
make it table-ish, then use regular SQL to pull out what you want.
--
Mike Rylander
| Resear
in Ful Text search regarding those file types?
>
It can't handle those without some help -- it supports exactly text --
but you can extract the text using other tools.
--
Mike Rylander
| Executive Director
| Equinox Open Library Initiative
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@
well. Our main
performance issue has to do with all of the stuff outside the records
(documents) themselves that have to be taken into account during
search. The core full-text search part of our queries is extremely
performant, and has only gotten better over the years.
[1] http://evergreen-ils.org
HT
t were modified as a JSON
blob, and let the application do whatever needs to be done to react
the the changes -- issue other queries, etc.
Of course that depends on your application knowing when it's
appropriate to NOTIFY, or being able to handle spurious NOTIFYs.
HTH,
--
Mike Rylander
| Exec
org/docs/10/static/datatype-datetime.html
on table 8.13, you can use special input values:
SELECT * FROM t WHERE ts >= 'today'::timestamp AND ts < 'tomorrow'::timestamp;
HTH,
--
Mike Rylander
| Executive Director
| Equinox Open Library Initiative
| phone: 1-877-OPEN-ILS (673-6457)
| em
nged to 'c' directly.
So, my question is, will updating pg_constraint "just work" (for, say,
new sessions, after forcing clients to reconnect) or would there be a
data risk?
Thanks in advance,
--
Mike Rylander
