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
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
Dear Postgres developers,
I have been working with Oracle for few years now in my work, and I tried some
free databases for a project that I'm developing for my own use, I have tried
H2,FireBird and postgres, and found the last to be the most stable and
feature-rich, so thanks for all the
[EMAIL PROTECTED] (Steve Atkins) writes:
Is there any existing work out there on this? Or should I maybe be
looking at prototyping something?
The skype tools have some sort of decent-looking publish/subscribe
thing, PgQ, then they layer their replication on top of. It's multi
consumer and
On Wed, June 20, 2007 04:45, Chris Browne wrote:
I'm seeing some applications where it appears that there would be
value in introducing asynchronous messaging, ala message queueing.
http://en.wikipedia.org/wiki/Message_queue
The granddaddy of message queuing systems is IBM's MQ-Series, and I
Hi Chris,
Chris Browne wrote:
I'm seeing some applications where it appears that there would be
value in introducing asynchronous messaging, ala message queueing.
http://en.wikipedia.org/wiki/Message_queue
ISTM that 'message queue' is a way too general term. There are hundreds
of different
On 6/20/07, Jeroen T. Vermeulen [EMAIL PROTECTED] wrote:
On Wed, June 20, 2007 04:45, Chris Browne wrote:
- Sometimes you have the semantics where:
- messages need to be delivered at least once
- messages need to be delivered no more than once
- messages need to be delivered exactly
Marko Kreen wrote:
As I understand, JMS does not have a concept
of transactions, probably also other solutions mentioned before,
so to use PgQ as backend for them should be much simpler...
JMS certainly does have the concept of transactions. Both distributed
ones through XA and two-phase
On 6/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Marko Kreen wrote:
As I understand, JMS does not have a concept
of transactions, probably also other solutions mentioned before,
so to use PgQ as backend for them should be much simpler...
JMS certainly does have the concept of
On Wed, June 20, 2007 18:18, Heikki Linnakangas wrote:
Marko Kreen wrote:
As I understand, JMS does not have a concept
of transactions, probably also other solutions mentioned before,
so to use PgQ as backend for them should be much simpler...
JMS certainly does have the concept of
Jeroen T. Vermeulen wrote:
On Wed, June 20, 2007 18:18, Heikki Linnakangas wrote:
Marko Kreen wrote:
As I understand, JMS does not have a concept
of transactions, probably also other solutions mentioned before,
so to use PgQ as backend for them should be much simpler...
JMS certainly does
Do you guys need something PG specific or built into PG?
ActiveMQ is very nice, speaks multiple languages, protocols and supports a ton
of features. Could you simply use that?
http://activemq.apache.org/
Rob
Bruce Momjian wrote:
Agreed. I don't see the point in following a standard few people know
about.
Few people in the US and UK you mean, right? Everybody else stopped
measuring in king's feet and thumbs a long time ago.
--
Alvaro Herrera
On Wed, June 20, 2007 19:42, Rob Butler wrote:
Do you guys need something PG specific or built into PG?
ActiveMQ is very nice, speaks multiple languages, protocols and supports a
ton of features. Could you simply use that?
http://activemq.apache.org/
Looks very nice indeed!
Jeroen
toronto programmer wrote:
Dear Postgres developers,
I have been working with Oracle for few years now in my work, and I
tried some free databases for a project that I'm developing for my own
use, I have tried H2,FireBird and postgres, and found the last to be
the most stable and
On 6/20/07, Rob Butler [EMAIL PROTECTED] wrote:
Do you guys need something PG specific or built into PG?
Yes, we need it usable from inside the DB, thus the PgQ.
That means the events are also transactional with other
things happening in the DB.
ActiveMQ is very nice, speaks multiple
[EMAIL PROTECTED] (Marko Kreen) writes:
To Chris: you should like PgQ, its just stored procs in database,
plus it's basically just generalized Slony-I, with some optimizations,
so should be familiar territory ;)
Looks interesting...
Random ideas
- insert_event in C (way to get
On Tuesday 19 June 2007 10:15, Tom Lane wrote:
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
On Wed, Jun 20, 2007 at 12:34:21PM -0400, Robert Treat wrote:
FWIW pg_migrator is a pretty good swing at an in-place upgrade tool for
8.1-8.2. Unfortunately until the PGDG decides that in-place upgrade is a
constraint their willing to place on development, I see them a good
chicken/egg
On 6/20/07, Chris Browne [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Marko Kreen) writes:
To Chris: you should like PgQ, its just stored procs in database,
plus it's basically just generalized Slony-I, with some optimizations,
so should be familiar territory ;)
Looks interesting...
Thanks
I've uploaded the latest test results to the results page at
http://community.enterprisedb.com/ldc/
The test results on the index page are not in a completely logical
order, sorry about that.
I ran a series of tests with 115 warehouses, and no surprises there. LDC
smooths the checkpoints
On Wed, 20 Jun 2007, Heikki Linnakangas wrote:
Another series with 150 warehouses is more interesting. At that # of
warehouses, the data disks are 100% busy according to iostat. The 90%
percentile response times are somewhat higher with LDC, though the
variability in both the baseline and LDC
Am Mittwoch, 20. Juni 2007 05:54 schrieb Bruce Momjian:
Agreed. I don't see the point in following a standard few people know
about.
Yes, let's drop SQL as well.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Oleg Bartunov wrote:
On Sun, 17 Jun 2007, Bruce Momjian wrote:
I have completed my first pass over the tsearch documentation:
http://momjian.us/expire/fulltext/HTML/sql.html
They are from section 14 and following.
I have come up with a number of questions that I placed in SGML
Peter Eisentraut wrote:
Am Mittwoch, 20. Juni 2007 05:54 schrieb Bruce Momjian:
Agreed. ?I don't see the point in following a standard few people know
about.
Yes, let's drop SQL as well.
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and
Greg Smith wrote:
I think it does a better job of showing how LDC can shift the top
percentile around under heavy load, even though there are runs where it's
a clear improvement. Since there is so much variability in results when
you get into this territory, you really need to run a lot of
On Wed, 20 Jun 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
On Sun, 17 Jun 2007, Bruce Momjian wrote:
I have completed my first pass over the tsearch documentation:
http://momjian.us/expire/fulltext/HTML/sql.html
They are from section 14 and following.
I have come up with a
Greg Smith wrote:
While it shows up in the 90% figure, what happens is most obvious in the
response time distribution graphs. Someone who is currently getting a
run like #295 right now: http://community.enterprisedb.com/ldc/295/rt.html
Might be really unhappy if they turn on LDC expecting to
Bruce Momjian wrote:
Greg Smith wrote:
I don't expect this patch to be perfect when it is applied. I do expect
to be a best effort, and it will get continual real-world testing during
beta and we can continue to improve this. Right now, we know we have a
serious issue with checkpoint I/O,
Joshua D. Drake wrote:
The only comment I have is that is could be useful to
be able to turn this feature off via GUC. Other than that, I think it is
great.
Yeah, you can do that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
Bruce Momjian [EMAIL PROTECTED] writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.
If we're not going
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.
On Wed, 20 Jun 2007, Heikki Linnakangas wrote:
You mean the shift and flattening of the graph to the right in the delivery
response time distribution graph?
Right, that's what ends up happening during the problematic cases. To
pick numbers out of the air, instead of 1% of the transactions
On Wed, 20 Jun 2007, Bruce Momjian wrote:
I don't expect this patch to be perfect when it is applied. I do expect
to be a best effort, and it will get continual real-world testing during
beta and we can continue to improve this.
This is completely fair. Consider my suggestions something
Bruce Momjian [EMAIL PROTECTED] writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is fine.
Could you expand on
Oleg Bartunov wrote:
On Wed, 20 Jun 2007, Bruce Momjian wrote:
Comments to editorial work of Bruce Momjian.
fulltext-intro.sgml:
it is useful to have a predefined list of lexemes.
Bruce, here should be list of types of lexemes !
Agreed. Are the list of lexemes parser-specific?
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If SQL was not a popular standard, we would drop it. You and Alvaro are
saying that 'm' for meter and 'min' for minute is commonly recognized
outside the USA/UK, so that is good enough for me to say that the
existing setup is
Bruce Momjian [EMAIL PROTECTED] writes:
I suppose the idea is that we don't want to be sloppy about accepting
just anything in postgresql.conf.
becuase?
I think people are worried that an 'm' in one column might mean something
different than an 'm' in another column, and perhaps that is
On Wed, Jun 20, 2007 at 5:21 PM, in message
[EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:
Gregory Stark wrote:
Could you expand on your logic here? And why you disagree with my argument
that which abbreviations are correct is irrelevant in deciding whether we
should accept
Alvaro Herrera [EMAIL PROTECTED] wrote:
Something worth considering, though unrelated to the topic at hand: what
happens with the table stats after CLUSTER? Should we cause an ANALYZE
afterwards? We could end up running with outdated statistics.
We don't invalidate the value statistics in
I found that the autovacuum launcher continues to run and spawn workers
after reloading the configuration file with autovacuum = off in CVS HEAD.
What should we do after autovacuum is disabled runtime? I think the
launcher should not spawn any new workers. It can be fixed easily,
but there are
41 matches
Mail list logo
