On 15/2/21 16:29, Adrian Klaver wrote:
On 2/15/21 1:15 PM, Joe Abbate wrote:
We've been experiencing PG server process crashes about every other
week on a mostly read only website (except for a single insert/update
on page access). Typical log entries look like
LOG: checkpointer pr
Hello,
We've been experiencing PG server process crashes about every other week
on a mostly read only website (except for a single insert/update on page
access). Typical log entries look like
LOG: checkpointer process (PID 11200) was terminated by signal 9: Killed
LOG: terminating any othe
Hello Gavan,
On 28/9/20 17:52, Gavan Schneider wrote:
Consider expressing all the component fields as a range. This allows you
the ability to be a precise as you need and still have the benefits of
well defined comparison functions.
I did consider that, but it's a tradeoff between 80% of the
Hello Tom,
On 28/9/20 17:25, Tom Lane wrote:
Domain-over-composite might be a slightly simpler answer than your first
one. It's only available in relatively late-model PG, and I'm not sure
about its performance relative to your other design, but it is an
alternative to think about.
"Domain-ov
Hello Rob,
On 28/9/20 17:17, Rob Sargent wrote:
just record all three fields (day, month, year) with nulls and do the to-date
as needed.
That is not sufficient. An earlier implementation had something like a
CHAR(8) to record MMDD, but how can you indicate, for example, an
issue date o
Hello,
I'm considering creating a TYPE for what may be called a "possibly
imprecise date" (pidate). The most obvious use is for recording dates
such as births or deaths of historical individuals, where we may know
that someone died precisely on a given year-month-day, but the birth may
only
I'm dealing with an issue where a query uses 'today'::date to select one
of a number of rows depending on the day modulo the number of rows. The
intent is that different information will be shown starting after
midnight local time. The query runs as expected in psql and using psycopg2.
Howeve
