Re: [HACKERS] Maximum reasonable bgwriter_delay

Greg Smith <[EMAIL PROTECTED]> writes: > I can't think of any good reason why the bgwriter_delay can't be reduced > to 1s if that simplifies things. The simplification Heikki suggests would save a grand total of 9 lines of C code, two of which are braces. Is it really worth it to make such strin

Re: [HACKERS] Maximum reasonable bgwriter_delay

On Tue, 19 Jun 2007, Heikki Linnakangas wrote: Simon Riggs wrote: Laptop mode? Linux has it... Granted, though you're still going to wake up every second, so I'm not sure how much it helps with battery life. In this context, Linux's laptop mode is all about keeping the disks from spinning

Re: [HACKERS] GUC time unit spelling a bit inconsistent

Simon Riggs wrote: > On Mon, 2007-06-18 at 20:02 +0200, Peter Eisentraut wrote: > > Am Montag, 18. Juni 2007 19:03 schrieb Tom Lane: > > > In time-related contexts (eg ISO 8601) I'd expect just "h" "m" and "s". > > > > ISO 8601 appears to use a slightly different syntax for writing timespans. >

Re: [HACKERS] PG-MQ?

On Jun 19, 2007, at 2:45 PM, Chris Browne wrote: I'm seeing some applications where it appears that there would be value in introducing asynchronous messaging, ala "message queueing." Me too. My bias would be to have something that can basically

[HACKERS] PG-MQ?

I'm seeing some applications where it appears that there would be value in introducing asynchronous messaging, ala "message queueing." The "granddaddy" of message queuing systems is IBM's MQ-Series, and I don't see particular value in replicating its fu

Re: [HACKERS] Maximum reasonable bgwriter_delay

Simon Riggs wrote: On Tue, 2007-06-19 at 15:53 +0100, Heikki Linnakangas wrote: The maximum for bgwriter_delay is currently 10 seconds. That's a long time, and in fact if you set it to a value greater than 1 s, the sleep is split into 1 s intervals with a call to AbsorbFsyncRequests in between

Re: [HACKERS] Rethinking user-defined-typmod before it's too late

On Fri, 2007-06-15 at 15:01 -0400, Stephen Frost wrote: > But we'd only get 31 bits of room to encode that into. I'm not sure if > that's enough. :( At the moment there's three columns we're talking > about in the side-table: > SRID (integer) > TYPE (varchar(30)) > DIMENSIONS (integer) > > Now,

Re: [HACKERS] Maximum reasonable bgwriter_delay

On Tue, 2007-06-19 at 15:53 +0100, Heikki Linnakangas wrote: > The maximum for bgwriter_delay is currently 10 seconds. That's a long > time, and in fact if you set it to a value greater than 1 s, the sleep > is split into 1 s intervals with a call to AbsorbFsyncRequests in > between them. > > I

Re: [HACKERS] GUC time unit spelling a bit inconsistent

On Mon, 2007-06-18 at 20:02 +0200, Peter Eisentraut wrote: > Am Montag, 18. Juni 2007 19:03 schrieb Tom Lane: > > In time-related contexts (eg ISO 8601) I'd expect just "h" "m" and "s". > > ISO 8601 appears to use a slightly different syntax for writing timespans. I > would not object if anyone

Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL

Jim, > I know there's issues with using ident sameuser via TCP, but what > about for filesystem socket connections? Not all OSes support ident ... Solaris and OpenBSD for two, don't, because they see ident as insecure. We switched the default to "trust localhost only" after many, many complaint

Re: [HACKERS] to partition or not to partition that is the question

Tim, > I have two types of tables, for sake of argument lets call it these: > > 1) product                  10,000,000 rows > 2) product_activity  1,000,000,000 rows pgsql-performance is the correct list for your question. Please re-post it there. -hackers is for PostgreSQL development. -- J

[HACKERS] Maximum reasonable bgwriter_delay

The maximum for bgwriter_delay is currently 10 seconds. That's a long time, and in fact if you set it to a value greater than 1 s, the sleep is split into 1 s intervals with a call to AbsorbFsyncRequests in between them. Is there a use case for a setting > 1 s? We could simplify that logic a

Re: What does Page Layout version mean? (Was: Re: [HACKERS] Reducing NUMERIC size for 8.3)

Zdenek Kotala <[EMAIL PROTECTED]> writes: > I'm little bit confused when we introduce new page layout version? I > expect that new version become with changes with pageheader, tuple > header or data encoding (varlen/TOAST ...). But in case when there is > new data type internal implementation, t

[HACKERS] to partition or not to partition that is the question

I have two types of tables, for sake of argument lets call it these: 1) product 10,000,000 rows 2) product_activity 1,000,000,000 rows 90% of the type the product table is accessed by product_id, 80% of the time that product id would be in the last 1,000,000 rows of the table i.

What does Page Layout version mean? (Was: Re: [HACKERS] Reducing NUMERIC size for 8.3)

Simon Riggs wrote: The objections to applying this patch originally were: 1. it changes on-disk format (we've done this, so argument is void) I'm little bit confused when we introduce new page layout version? I expect that new version become with changes with pageheader, tuple header or dat