On Wed, Jul 11, 2012 at 12:50 AM, Andreas wrote:
[...]
> I can't simply move rejected events in an archive table and keep a unique
> index on object_id as there are other descriptive tables that reference the
> event_log.id.
Would a multi-column index, unique on (id, state) meet your need?
rls
2012/1/17 Filip Rembiałkowski :
> postgres will still try to choose best execution plan. seq scan may simply be
> faster here. breaking point is somewhere near 50% selectivity.
The tipping point is usually far lower than that; in fact, it's more
often around 10%. Random IO is *very* expensive, a
On Tue, Jan 5, 2010 at 6:33 PM, Chris wrote:
> I'm trying to get extract() to always return the number of hours between two
> time intervals, ala:
SELECT extract(epoch from timeend - timestart) / 3600 from t1;
rls
--
:wq
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make c
On Tue, Dec 29, 2009 at 4:44 PM, Bryce Nesbitt wrote:
> Craig is correct in the OP attempt. All but one field is intended to be null
Ah; my misunderstanding, then. Sorry for the noise.
> Duplicate rows, or data in multiple columns, would wreck havoc on the
> scheme. If there is a better way
On Wed, Dec 23, 2009 at 1:44 AM, Craig Ringer
wrote:
> SELECT COALESCE( t_number::text, t:string::text, t_date::text,
> t_boolean::text) AS value;
Your invocation of COALESCE is incorrect -- it is n-ary, but it
returns its first non-NULL argument. Instead, try:
SELECT
COALESCE(t_number::te
while you weren't looking, Derek Buttineau|Compu-SOLVE wrote:
> I'm hoping this is the right place to send this.
The PostgreSQL Performance list, pgsql-performance@postgresql.org
would be more appropriate. I'm copying my followup there, as well.
As for your query, almost all the time is actually
A colleague has the following query, which errors with: relation "dl"
does not exist. (See the second item in the FROM clause.) If that
item is moved to immediately precede the first JOIN item however, the
query works as expected.
select u.usersfirstname || ' ' || u.userslastname as userssuperv
while you weren't looking, Andreas Joseph Krogh wrote:
> Any idea how to achieve this?
...
ORDER BY coalesce(start_date, '1900-01-01') ASC
, coalesce(start_time, '1900-01-01') ASC;
/rls
--
:wq
---(end of broadcast)---
TIP 6: Have you searc
while you weren't looking, KÖPFERL Robert wrote:
> ERROR: syntax error at or near "TYPE" at character 47
What version are you running? To my knowledge, altering the type of a
column is a new feature to 8.0.
/rls
--
:wq
---(end of broadcast)---
while you weren't looking, Tom Lane wrote:
> Does the other case have any partial indexes?
No it doesn't, and I caught it on reflection.
> I'd describe that as "miraculously managing not to
> fail", though, not as a behavior I'd care to rely on.
Most definitely not; it's already changed.
/rls
while you weren't looking, Tom Lane wrote:
[...]
> If you want to encapsulate this set of operations in a function, I'd
> suggest using plpgsql and being careful to EXECUTE each query rather
> than letting plpgsql try to cache a plan for it.
We've opted to simply script issuing the statements se
Philippe Lang wrote:
> The problem now is that get_lines is being called twice per line.
Is get_lines() defined as IMMUTABLE? Should it be?
/rls
--
:wq
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
while you weren't looking, Caleb Simonyi-Gindele <[EMAIL PROTECTED]> wrote:
> How do I get it to produce a row even when dat_staff_code is null?
try something like
SELECT coalesce(dat_staff_code, 0)...GROUP BY dat_staff_code
That will substitute a zero for any NULL value in that column, which
G
On Fri, 25 Jun 2004 08:16:47 +0400, sad <[EMAIL PROTECTED]> wrote:
> > Very simply, a boolean may have to values: true or false. It's also
> > possible that it's not been set to anything (NULL).
> really ?
> what about (13 < NULL)::BOOL
Per the semantics of NULL, 13 is neither greater than no
14 matches
Mail list logo
