From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
ow...@postgresql.org] On Behalf Of Clark Slater
Sent: Tuesday, July 14, 2009 10:04 AM
Subject: [GENERAL] filter duplicates by priority
Maybe I'm missing something, but why not something like (incoming
pseudo-SQL):
Select
-Original Message-
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
ow...@postgresql.org] On Behalf Of Brandon Metcalf
Sent: Friday, July 10, 2009 12:16 PM
Change it to this:
SELECT t.name AS machine_type_name,
j.workorder,
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
ow...@postgresql.org] On Behalf Of Brandon Metcalf
Sent: Friday, July 10, 2009 12:16 PM
Change it to this:
Sorry, I forgot that you need to split the GROUP BY clause as well in a
similar manner to the WHERE clause. And
Dennis Gearon
Sent: Tuesday, July 07, 2009 9:46 PM
When locking is involved, does a transaction wait for access to a row
or
table, or does it just fail back to the calling code? Would it be up
to my
PHP code to keep hammeing for access to a row/table, or could a user
defined function do
Try this.
select idn,
array_to_string(array(select code from tbl t2 where
t2.idn = t1.idn order by code), ', ') as codes
fromtbl t1
group byidn
order byidn
Matthew Hartman
Programmer/Analyst
Information Management, ICP
Kingston General Hospital
If it's static (i.e. the planets don't move too much, hah), calculate
and store. No sense in re-calculating it each and every time.
Matthew Hartman
Programmer/Analyst
Information Management, ICP
Kingston General Hospital
(613) 549- x4294
-Original Message-
From:
Good morning.
I am itching to upgrade my 8.3 development database to 8.4 before I move
to production. Pg_migrator is listed as beta so I'd like to avoid that.
Has anyone made the leap yet?
Matthew Hartman
Programmer/Analyst
Information Management, ICP
Kingston General Hospital
(613)
Just create a unique constraint on all of the columns.
Matthew Hartman
Programmer/Analyst
Information Management, ICP
Kingston General Hospital
(613) 549- x4294
-Original Message-
From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
ow...@postgresql.org] On Behalf
Good morning.
On occasion I'll perform a full vacuum on a database but will still
receive a suggestion to vacuum an individual table immediately after.
Does the full database vacuum not handle each individual table?
Thanks,
Matthew Hartman
Programmer/Analyst
Information Management, ICP
[mailto:gryz...@gmail.com]
Sent: Thursday, June 25, 2009 11:25 AM
To: Hartman, Matthew
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Vacuum on the database versus individual tables.
On Thu, Jun 25, 2009 at 3:40 PM, Hartman,
Matthewmatthew.hart...@krcc.on.ca wrote:
On occasion I'll
Kingston General Hospital
(613) 549- x4294
-Original Message-
From: Dave Page [mailto:dp...@pgadmin.org]
Sent: Thursday, June 25, 2009 12:00 PM
To: Grzegorz Jaśkiewicz
Cc: Hartman, Matthew; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Vacuum on the database versus individual
: Thursday, June 25, 2009 12:10 PM
To: Hartman, Matthew
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Vacuum on the database versus individual tables.
On Thu, Jun 25, 2009 at 10:40 AM, Hartman,
Matthewmatthew.hart...@krcc.on.ca wrote:
Good morning.
On occasion I'll perform a full vacuum
Is there a recommended approach when trying to use EXPLAIN on a
function? Specifically, a function that is more than the typical SELECT
statement or tiny loop. The one in question that I'm hoping to optimize
is around 250 lines.
Thanks,
Matthew Hartman
Programmer/Analyst
Information Management,
[mailto:mmonc...@gmail.com]
Sent: Tuesday, June 23, 2009 9:20 AM
To: Hartman, Matthew
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Explaining functions.
On Tue, Jun 23, 2009 at 8:03 AM, Hartman,
Matthewmatthew.hart...@krcc.on.ca wrote:
Is there a recommended approach when trying to use EXPLAIN
: Tuesday, June 23, 2009 10:48 AM
To: Hartman, Matthew; 'Merlin Moncure'
Cc: pgsql-general@postgresql.org
Subject: RE: [GENERAL] Explaining functions.
is around 250 lines.
What I normally do for benchmarking of complex functions is to
sprinkle the source with raise notice '%', timeofday
Isn't a many-to-one relationship the classic example of a child table?
Have one parent table that assigns a primary key. PARENT with PARENT_ID.
Have a child table that has a name and value column. CHILD with PARENT_ID,
COLUMN_NAME, and COLUMN_VALUE. Perform joins as you see fit to build up
16 matches
Mail list logo
