- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
Tom said that our low-hanging fruit is gone and only hard
items are
left. This is certainly true. What is hard to accept is that
those big
items take _weeks_ of focused development, and we just don't
have enough
full-time
Tom Lane wrote:
I spent weeks doing hash aggregates, weeks doing IN-subselect
optimization, and am in the middle of many weeks on FE/BE protocol
improvement. I am sorry that you don't see these as killer features
... but they are all things that we desperately needed to do.
For me, the 7.4
Mike Mascari wrote:
I was disappointed that Satoshi Nagayasu's two-phase commit
patches seemed to be implicitly rejected by lack of an
enthusiastic response by any of the core members. Distributed
query (not replication) would have been a very nice feature.
It's what separates, in part,
Tom Lane wrote:
BTW, I would not approve of a response along the lines of can't you
#ifdef to the point that there are no code changes in the Unix builds?
No you can't, unless you want to end up with an unmaintainable mess
of #ifdef spaghetti. The thing that makes this hard is the tradeoff
Dann Corbit wrote:
PostgreSQL's regression tests (IMHO) are much better than
MySQL's crash-me scripts.
They are less thorough in coverage, but not too bad.
Right, we are still missing this test that proves 10,000 CREATE+DROP
TABLE will ensure that PostgreSQL is slower than MySQL, if you don't
Dann Corbit wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Are you volunteering to create it? Step right up.
No. And as an outsider, I rather doubt if any procedures I developed
would be taken very seriously. If such procedures are to be developed,
I suspect that
Alvaro Herrera wrote:
Also they don't test things they don't support. Is there a test for
subselects? What about concurrency? Transactional issues? What about
performance when they have their transaction support enabled?
Sure don't they. Like their NUMERIC data type, that can *store* any
On Sun, 2003-06-22 at 07:44, Bruce Momjian wrote:
Mike Mascari wrote:
I was disappointed that Satoshi Nagayasu's two-phase commit
patches seemed to be implicitly rejected by lack of an
enthusiastic response by any of the core members. Distributed
They weren't ready to be committed at the
Jan Wieck wrote:
Tom Lane wrote:
BTW, I would not approve of a response along the lines of can't you
#ifdef to the point that there are no code changes in the Unix builds?
No you can't, unless you want to end up with an unmaintainable mess
of #ifdef spaghetti. The thing that makes this
On Sun, 22 Jun 2003, Bruce Momjian wrote:
Mike Mascari wrote:
I was disappointed that Satoshi Nagayasu's two-phase commit
patches seemed to be implicitly rejected by lack of an
enthusiastic response by any of the core members. Distributed
query (not replication) would have been a very
On Sat, 21 Jun 2003, Bruce Momjian wrote:
That's a tough call. I do worry about readability. We have made Win32
changes, and they aren't ifdefs, and we still have a running system, and
I think we can do that for PITR too. I think the big issue, which may be
your point, is to get incremental
The reason I mention it is that Postgres already supports
O_DIRECT I think on some other platforms (for whatever
reason).
[ sounds of grepping... ] No. The only occurrence of O_DIRECT in the
source tree is in TODO:
* Consider use of open/fcntl(O_DIRECT) to minimize
This change (I'm sure this will wrap poorly -- sorry):
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85r2=1.86
modified SockAddr, but no corresponding change was made here
(fe-auth.c:612):
case AUTH_REQ_KRB5:
#ifdef KRB5
if
On Fri, 20 Jun 2003, Dann Corbit wrote:
Designing tests is busywork. Desiging tests is boring. Nobody wants to
design tests, let alone interpret the results and define correct
baselines. But testing is very, very important.
But we do do testing ... we even design testing (in the form of
On Sat, 21 Jun 2003, Dann Corbit wrote:
It seems pretty clear that there are warts on the Crashme test.
Perhaps 70% or so is truly useful. Maybe the useful subset could be
approximated or modified to be useful as a general tool set.
And we all wait with baited breath for you to develop and
The Hermit Hacker wrote:
On Sun, 22 Jun 2003, Bruce Momjian wrote:
Mike Mascari wrote:
I was disappointed that Satoshi Nagayasu's two-phase commit
patches seemed to be implicitly rejected by lack of an
enthusiastic response by any of the core members. Distributed
query (not replication) would
The Hermit Hacker wrote:
On Fri, 20 Jun 2003, Dann Corbit wrote:
Designing tests is busywork. Desiging tests is boring. Nobody wants to
design tests, let alone interpret the results and define correct
baselines. But testing is very, very important.
But we do do testing ... we even design
On Sun, 22 Jun 2003, Jan Wieck wrote:
The Hermit Hacker wrote:
On Fri, 20 Jun 2003, Dann Corbit wrote:
Designing tests is busywork. Desiging tests is boring. Nobody wants to
design tests, let alone interpret the results and define correct
baselines. But testing is very, very
Bruce Momjian writes:
I have added a cleaned up version of this to CVS as src/tools/pgtest.
This seems to be a platform-specific reimplementation of 'make clean; make
check'. Why bother?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
- Original Message -
From: Jeroen T. Vermeulen [EMAIL PROTECTED]
I ran into the same need (Bruce, we discussed this at FOSDEM in Brussels
this February) for libpqxx. My code tries to compensate for the
possibility that the backend connection is lost while waiting for a reply
to a
The Hermit Hacker wrote:
And, actually, for some reason I hadn't thought of the tsearch as being
another 'INDEX' type ... I crawl back over and be quiet now :)
Oleg, as far as commits are concerned, I have no problems with extending
the privileges to one of your guys for this, just email
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Why does the interval type not print seconds when they are zero?
Seems like a bug to me too. Anyone think it's not?
Note this only occurs with DateStyle = ISO, the other datestyles
use a different format for intervals.
Clearly
What you really want is Solaris's free-behind, where it detects if a
scan is exceeding a certain percentage of the OS cache and moves the
pages to the _front_ of the to-be-reused list. I am not sure what other
OS's support this, but we need this on our own buffer manager code as
well.
Our TODO
Peter Eisentraut wrote:
Bruce Momjian writes:
I have added a cleaned up version of this to CVS as src/tools/pgtest.
This seems to be a platform-specific reimplementation of 'make clean; make
check'. Why bother?
Marc requested it. Is there anything platform-specific except the greps?
What you really want is Solaris's free-behind, where it detects if a
scan is exceeding a certain percentage of the OS cache and moves the
pages to the _front_ of the to-be-reused list. I am not sure what
other OS's support this, but we need this on our own buffer manager
code as well.
Our
Sean Chittenden wrote:
What you really want is Solaris's free-behind, where it detects if a
scan is exceeding a certain percentage of the OS cache and moves the
pages to the _front_ of the to-be-reused list. I am not sure what
other OS's support this, but we need this on our own buffer
What you really want is Solaris's free-behind, where it detects
if a scan is exceeding a certain percentage of the OS cache and
moves the pages to the _front_ of the to-be-reused list. I am
not sure what other OS's support this, but we need this on our
own buffer manager code as
Let me add my two cents ..
I think something like PostgreSQL needs two test suites - an
acceptance test (to ensure that checkins don't break functionality)
and a regression test suite.
What we call the regression test suite is really an acceptance
test. Tom Lane is absolutely right in asserting
On Sun, 22 Jun 2003, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian writes:
I have added a cleaned up version of this to CVS as src/tools/pgtest.
This seems to be a platform-specific reimplementation of 'make clean; make
check'. Why bother?
Marc requested it. Is
Basically, we don't know when we read a buffer whether this is a
read-only or read/write. In fact, we could read it in, and another
backend could write it for us.
The big issue is that when we do a write, we don't wait for it to get to
disk.
It seems to use O_DIRECT, we would have to read the
Kevin Jacobs [EMAIL PROTECTED] writes:
Attached is a patch that removes all of the RExec code from plpython from
the current PostgreSQL CVS. In addition, plpython needs to be changed to an
untrusted language in createlang.
I am inclined to rename plpython to plpythonu, by analogy to pltclu.
Basically, we don't know when we read a buffer whether this is a
read-only or read/write. In fact, we could read it in, and another
backend could write it for us.
Um, wait. The cache is shared between backends? I don't think so,
but it shouldn't matter because there has to be a semaphore
Sean Chittenden wrote:
Basically, we don't know when we read a buffer whether this is a
read-only or read/write. In fact, we could read it in, and another
backend could write it for us.
Um, wait. The cache is shared between backends? I don't think so,
but it shouldn't matter because
Bruce Momjian [EMAIL PROTECTED] writes:
I sure want two-phase commit. I don't remember it as being rejected,
and we certainly need it, independent of replication.
Is 2PC a real-world solution to any real-world problem? I have never
seen a satisfactory explanation of what you do when you've
Bruce Momjian [EMAIL PROTECTED] writes:
Basically, I think we need free-behind rather than O_DIRECT.
There are two separate issues here --- one is what's happening in our
own cache, and one is what's happening in the kernel disk cache.
Implementing our own free-behind code would help in our own
Bruce Momjian [EMAIL PROTECTED] writes:
_That_ is an excellent point. However, do we know at the time we open
the file descriptor if we will be doing this?
We'd have to say on a per-read basis whether we want O_DIRECT or not,
and fd.c would need to provide a suitable file descriptor.
What
Tom Lane wrote:
Wang Mike [EMAIL PROTECTED] writes:
but this query: select * from test_uuid where id =
'df2b10aa-a31d-11d7-9867-0050babb6029'::uuid dosn't use index
QUERY PLAN
---
Seq Scan on
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Basically, I think we need free-behind rather than O_DIRECT.
There are two separate issues here --- one is what's happening in our
own cache, and one is what's happening in the kernel disk cache.
Implementing our own free-behind code
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
_That_ is an excellent point. However, do we know at the time we open
the file descriptor if we will be doing this?
We'd have to say on a per-read basis whether we want O_DIRECT or not,
and fd.c would need to provide a suitable file
Basically, I think we need free-behind rather than O_DIRECT.
There are two separate issues here --- one is what's happening in
our own cache, and one is what's happening in the kernel disk cache.
Implementing our own free-behind code would help in our own cache
but does nothing for the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I sure want two-phase commit. I don't remember it as being rejected,
and we certainly need it, independent of replication.
Is 2PC a real-world solution to any real-world problem? I have never
seen a satisfactory explanation of what
What about cache coherency problems with other backends not
opening with O_DIRECT?
If O_DIRECT introduces cache coherency problems against other
processes not using O_DIRECT then the whole idea is a nonstarter,
but I can't imagine any kernel hackers would have been stupid
enough
Bruce Momjian [EMAIL PROTECTED] writes:
True, it is a cost/benefit issue. My assumption was that once we have
free-behind in the PostgreSQL shared buffer cache, the kernel cache
issues would be minimal, but I am willing to be found wrong.
If you are running on the
On Sun, 22 Jun 2003, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I sure want two-phase commit. I don't remember it as being rejected,
and we certainly need it, independent of replication.
Is 2PC a real-world solution to any real-world problem? I
Sean Chittenden [EMAIL PROTECTED] writes:
it doesn't seem totally out of the question. I'd kinda like to see
some experimental evidence that it's worth doing though. Anyone
care to make a quick-hack prototype and do some measurements?
What would you like to measure? Overall system
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's a cool-sounding phrase that does not actually work in
practice.
I think 2PC can be used to build more complex features,
Only if it works to begin with. If it's unreliable, what are you gonna
build on it?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's a cool-sounding phrase that does not actually work in
practice.
I think 2PC can be used to build more complex features,
Only if it works to begin with. If it's unreliable, what are you gonna
build
Weiping He [EMAIL PROTECTED] writes:
the situation trun worse: now the explain shows the query using the
index,
the we can't select out the match row! Any hint about what's wrong
with us?
My bet: either your operators are broken or your operator class
definition is wrong.
True, it is a cost/benefit issue. My assumption was that once we have
free-behind in the PostgreSQL shared buffer cache, the kernel cache
issues would be minimal, but I am willing to be found wrong.
If you are running on the
small-shared-buffers-and-large-kernel-cache theory, then
Sean Chittenden wrote:
Nor could it ever be a win unless the cache was populated via
O_DIRECT, actually. Big PG cache == 2 extra copies of data, once in
the kernel and once in PG. Doing caching at the kernel level, however
means only one copy of data (for the most part). Only problem with
Bruce Momjian [EMAIL PROTECTED] writes:
The question was whether 2PC is useful. The question wasn't if an
unreliable 2PC was useful.
My question is whether there is such a thing as reliable 2PC. I sure
don't see how you build that.
regards, tom lane
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
The question was whether 2PC is useful. The question wasn't if an
unreliable 2PC was useful.
My question is whether there is such a thing as reliable 2PC. I sure
don't see how you build that.
Other databases use 2PC --- are you
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I sure want two-phase commit. I don't remember it as being rejected,
and we certainly need it, independent of replication.
Is 2PC a real-world solution to any real-world problem? I have never
seen a satisfactory explanation of what you do
Bruce Momjian [EMAIL PROTECTED] writes:
Other databases use 2PC --- are you saying none of them are reliable?
Perhaps they're just smarter than I am. My question stands: what do
you do when the controller doesn't respond after you promise to commit?
Without a believable answer to that, I have
On Wed, 18 Jun 2003 02:58 pm, Philip Yarra wrote:
Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches
have been applied, and configure --with-threads is also added. I
have been doing some testing, and I still encounter a
threading problem.
For those interested, I tested this on
Bruce == Bruce Momjian [EMAIL PROTECTED] writes:
Bruce Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes: The question
was whether 2PC is useful. The question wasn't if an
unreliable 2PC was useful.
My question is whether there is such a thing as reliable
Added to TODO:
* Change CVS $Id$ to $PostgreSQL$
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Is this a dead issue? I know several people said they wanted it.
I'm willing to do it if people
it doesn't seem totally out of the question. I'd kinda like to
see some experimental evidence that it's worth doing though.
Anyone care to make a quick-hack prototype and do some
measurements?
What would you like to measure? Overall system performance when a
query is using O_DIRECT
Jan Wieck [EMAIL PROTECTED] writes:
The other problem I was missing being addressed is what happens if one
promised I can commit and crashes? Not exactly at the time he crashes,
but more at the time he restarts? Doesn't he have to restart into
exactly that state of I can commit, with all
Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
I'm not sure if I understand Tom's beef - I think he is concerned
about what happens if a subordinate does not respond to a prepare
message. I would assume that the co-ordinator would not let the commit
go through until it has received
Nor could it ever be a win unless the cache was populated via
O_DIRECT, actually. Big PG cache == 2 extra copies of data, once
in the kernel and once in PG. Doing caching at the kernel level,
however means only one copy of data (for the most part). Only
problem with this being that
No. I want to know what the subordinate does when it's promised to
commit and the co-ordinator never responds. AFAICS the subordinate
is screwed --- it can't commit, and it can't abort, and it can't expect
to make progress indefinitely on other work while it's holding locks
for the
Sean Chittenden wrote:
Nor could it ever be a win unless the cache was populated via
O_DIRECT, actually. Big PG cache == 2 extra copies of data, once
in the kernel and once in PG. Doing caching at the kernel level,
however means only one copy of data (for the most part). Only
On Sun, 22 Jun 2003, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's a cool-sounding phrase that does not actually work in
practice.
I think 2PC can be used to build more complex features,
Only if it works to begin
On Mon, 23 Jun 2003, Sailesh Krishnamurthy wrote:
I'm not sure if I understand Tom's beef - I think he is concerned about
what happens if a subordinate does not respond to a prepare message. I
would assume that the co-ordinator would not let the commit go through
until it has received
On Mon, 23 Jun 2003, Christopher Kings-Lynne wrote:
No. I want to know what the subordinate does when it's promised to
commit and the co-ordinator never responds. AFAICS the subordinate
is screwed --- it can't commit, and it can't abort, and it can't expect
to make progress indefinitely
The Hermit Hacker [EMAIL PROTECTED] writes:
Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the
co-ordinator crashes?
Or you just lose the network connection for awhile. The worst case
scenario I think is where the co-ordinator got everyone's promise to
commit, and told some
Hi.
I implement 2Q algorithm to PostgreSQL for buffer management , instead
of LRU.
It's known as low overhead and high performance than LRU. If you have
some interests , see following URL.
http://www.vldb.org/conf/1994/P439.PDF
In my test (pgbench -S) , it improves 4% cache hit rate and 2% up
Tom == Tom Lane [EMAIL PROTECTED] writes:
Tom Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
I'm not sure if I understand Tom's beef - I think he is
concerned about what happens if a subordinate does not respond
to a prepare message. I would assume that the co-ordinator
Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the
co-ordinator crashes?
Or you just lose the network connection for awhile. The worst case
scenario I think is where the co-ordinator got everyone's promise to
Add to TODO:
* Allow SSL-enabled clients to turn off SSL transfers
---
Tom Lane wrote:
Nigel J. Andrews [EMAIL PROTECTED] writes:
Ok, I tried to try this but I can not get SSL to _not_ be used when
connecting
71 matches
Mail list logo
