ust be changed 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
uning everything works 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
y
> constraints 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 (67
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-
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
|
nd an index on date_trunc('minute',timer) will be
useful, 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,
