[Mark Kirkwood - Fri at 03:01:01PM +1200]
> Tobias,
> Interesting example:
>
> The 'desc' seems to be the guy triggering the sort, e.g:
Oh; really an accident that I didn't notice myself, I was actually going to
remove all instances of "desc" in my simplification, but seems like I forgot.
> Howe
>I have a pl/pgsql function that using temp
table to perform searching logic,
>we have one
server running on 512MB, Red Hat 9.0, postgresql-7.4.5.
>the problem is the pl/pgsql function that i
created will increase postmaster memory when calling to function
>become more frequent, i did a test
Tobias,
Interesting example:
The 'desc' seems to be the guy triggering the sort, e.g:
explain select c.id from c join b on c_id=c.id group by c.id order by
c.id limit 5;
QUERY PLAN
---
On Thu, 2005-08-25 at 18:56 -0700, Jeffrey W. Baker wrote:
> On Fri, 2005-08-26 at 02:27 +0200, Tobias Brox wrote:
> > Consider this setup - which is a gross simplification of parts of our
> > production system ;-)
> >
> > create table c (id integer primary key);
> > create table b (id integer
[Jeffrey W. Baker - Thu at 06:56:59PM -0700]
> > explain select c.id from c join b on c_id=c.id group by c.id order by c.id
> > desc limit 5;
>
> Where's b in this join clause?
"join b on c_id=c.id"
It just a funny way of writing:
select c.id from c,b where c_id=c.id group by c.id order by c.
On Fri, 2005-08-26 at 02:27 +0200, Tobias Brox wrote:
> Consider this setup - which is a gross simplification of parts of our
> production system ;-)
>
> create table c (id integer primary key);
> create table b (id integer primary key, c_id integer);
> create index b_on_c on b(c_id)
>
>
Consider this setup - which is a gross simplification of parts of our
production system ;-)
create table c (id integer primary key);
create table b (id integer primary key, c_id integer);
create index b_on_c on b(c_id)
insert into c (select ... lots of IDs ...);
insert into b (select id
At 04:49 PM 8/25/2005, Chris Browne wrote:
[EMAIL PROTECTED] (Ron) writes:
> At 03:45 PM 8/25/2005, Josh Berkus wrote:
>> > Ask me sometime about my replacement for GNU sort. Â It uses the
>> > same sorting algorithm, but it's an order of magnitude faster due
>> > to better I/O strategy. Â Someda
[EMAIL PROTECTED] (Ron) writes:
> At 03:45 PM 8/25/2005, Josh Berkus wrote:
>> > Ask me sometime about my replacement for GNU sort. Â It uses the
>> > same sorting algorithm, but it's an order of magnitude faster due
>> > to better I/O strategy. Â Someday, in my infinite spare time, I
>> > hope to
At 03:45 PM 8/25/2005, Josh Berkus wrote:
Jeff,
> Ask me sometime about my replacement for GNU sort. Â It uses the same
> sorting algorithm, but it's an order of magnitude faster due to better
> I/O strategy. Â Someday, in my infinite spare time, I hope to demonstrate
> that kind of improvement
Andrew Lazarus <[EMAIL PROTECTED]> writes:
> Should I temporarily increase sort_mem, vacuum_mem, neither, or both
> when doing a CLUSTER on a large (100 million row) table
The only part of that job that can use lots of memory is the index
rebuilds. In recent PG versions maintenance_work_mem is t
Jeff,
> Ask me sometime about my replacement for GNU sort. It uses the same
> sorting algorithm, but it's an order of magnitude faster due to better
> I/O strategy. Someday, in my infinite spare time, I hope to demonstrate
> that kind of improvement with a patch to pg.
Since we desperately need
Andrew,
On Thu, 2005-08-25 at 12:24 -0700, Andrew Lazarus wrote:
> Should I temporarily increase sort_mem, vacuum_mem, neither, or both
> when doing a CLUSTER on a large (100 million row) table where as many as
> half of the tuples are deadwood from UPDATEs or DELETEs? I have large
> batch (10
Should I temporarily increase sort_mem, vacuum_mem, neither, or both
when doing a CLUSTER on a large (100 million row) table where as many as
half of the tuples are deadwood from UPDATEs or DELETEs? I have large
batch (10 million row) inserts, updates, and deletes so I'm not sure
frequent vacuu
On Thu, 2005-08-25 at 11:16 -0400, Ron wrote:
> ># - Settings -
> >
> >fsync = false # turns forced synchronization on or off
> >#wal_sync_method = fsync# the default varies across platforms:
> > # fsync, fdatasync, open_sync, or
>
> I hope
> Putting pg_xlog on the IDE drives gave about 10% performance
> improvement. Would faster disks give more performance?
>
> What my application does:
>
> Every five minutes a new logfile will be imported. Depending on the
> source of the request it will be imported in one of three "raw click"
> t
At 03:10 AM 8/25/2005, Ulrich Wisser wrote:
I realize I need to be much more specific. Here is a more detailed
description of my hardware and system design.
Pentium 4 2.4GHz
Memory 4x DIMM DDR 1GB PC3200 400MHZ CAS3, KVR
Motherboard chipset 'I865G', two IDE channels on board
First suggestion
On Thu, 25 Aug 2005 09:10:37 +0200
Ulrich Wisser <[EMAIL PROTECTED]> wrote:
> Pentium 4 2.4GHz
> Memory 4x DIMM DDR 1GB PC3200 400MHZ CAS3, KVR
> Motherboard chipset 'I865G', two IDE channels on board
> 2x SEAGATE BARRACUDA 7200.7 80GB 7200RPM ATA/100
> (software raid 1, system, swap, pg_xlog)
> A
--On Mittwoch, August 24, 2005 16:26:40 -0400 Chris Hoover
<[EMAIL PROTECTED]> wrote:
On 8/24/05, Merlin Moncure <[EMAIL PROTECTED]> wrote:
Linux does a pretty good job of deciding what to cache. I don't think
this will help much. You can always look at partial indexes too.
Yes, but won't
Hello,
I realize I need to be much more specific. Here is a more detailed
description of my hardware and system design.
Pentium 4 2.4GHz
Memory 4x DIMM DDR 1GB PC3200 400MHZ CAS3, KVR
Motherboard chipset 'I865G', two IDE channels on board
2x SEAGATE BARRACUDA 7200.7 80GB 7200RPM ATA/100
(softwa
20 matches
Mail list logo
