On Mon, Mar 5, 2012 at 3:15 PM, Merlin Moncure wrote:
> I've complained many times that
> select (f()).*;
>
> will execute f() once for each returned field of f() since the server
> essentially expands that into:
>
> select f().a, f().b;
>
oh, this is why we expand rows inside a WITH statement.
I've complained many times that
select (f()).*;
will execute f() once for each returned field of f() since the server
essentially expands that into:
select f().a, f().b;
try it yourself, see:
create function f(a out text, b out text) returns record as $$
begin
perform pg_sleep(1);
a := 'a';
Hi, a few personal opinions (your mileage may wary ...)
On 5.3.2012 23:37, Mark Kirkwood wrote:
> Where I work we are starting to look at using SSDs for database server
> storage. Despite the higher per unit cost it is quite attractive to
> replace 6-8 SAS drives in RAID 10 by a pair of SSD in RAI
Where I work we are starting to look at using SSDs for database server
storage. Despite the higher per unit cost it is quite attractive to
replace 6-8 SAS drives in RAID 10 by a pair of SSD in RAID 1 that will
probably perform better and use less power.
Which brings up the question of should i
On 05/03/12, Craig James (cja...@emolecules.com) wrote:
> On Sun, Mar 4, 2012 at 10:36 AM, Rory Campbell-Lange <
> r...@campbell-lange.net> wrote:
>
> > We do have complex transactions, but I haven't benchmarked the
> > performance so I can't describe it. Few of the databases are at the many
> > m
On Sun, Mar 4, 2012 at 10:36 AM, Rory Campbell-Lange <
r...@campbell-lange.net> wrote:
> We do have complex transactions, but I haven't benchmarked the
> performance so I can't describe it. Few of the databases are at the many
> million row size at the moment, and we are moving to an agressive sch
Thanks for pointing me to that article. I totally forgot that the postgres wiki
existed.
Updating is not an option at the moment, but we'll probably do so in the
future. Until then I can
live with the workaround.
Kind regards,
Marc
--
Sent via pgsql-performance mailing list (pgsql-perfor
On 5 Březen 2012, 16:11, Marc Schablewski wrote:
> We have an optimizer problem regarding partitioned tables on 8.4.11.
...
> gdw=> explain select min( emg_id ) from edifactmsgpart;
> QUERY PLAN
>
We have an optimizer problem regarding partitioned tables on 8.4.11.
We started partitioning a large table containing approx. 1 billion records.
So far, there is only the master table, called edifactmsgpart (which is empty)
and 1 partition,
called edifactmsgpart_pact.
There is a bigint column ca
On 04/03/12, Scott Marlowe (scott.marl...@gmail.com) wrote:
> On Sun, Mar 4, 2012 at 11:36 AM, Rory Campbell-Lange
> wrote:
> > On 04/03/12, Scott Marlowe (scott.marl...@gmail.com) wrote:
...
[Description of system with 2 * 4 core Xeons, 8GB RAM, LSI card with
4*15K SCSI drives in R10. We are look
10 matches
Mail list logo
