On Thu, 7 Oct 2004, Bruce Momjian wrote:
Added to TODO:
* Consider parallel processing a single query
This would involve using multiple threads or processes to do optimization,
sorting, or execution of single query. The major advantage of such a
feature would be to allow multiple CPUs to work
Marc G. Fournier wrote:
On Thu, 7 Oct 2004, Bruce Momjian wrote:
Added to TODO:
* Consider parallel processing a single query
This would involve using multiple threads or processes to do optimization,
sorting, or execution of single query. The major advantage of such a
Neil Conway wrote:
Marc G. Fournier wrote:
Do we have 'make backend thread safe' listed yet? As I recall it, until
that gets done, parallelization of anything was considered to be a
relatively onerous task, no?
ISTM there's no reason we couldn't parallelize query execution using the
A while back I was looking the backend code in preparation to start
beginning to look at parallelization techniques for PG ;)... My
thought was instead of trying to parallelize each individual plan node
(multi-process sort, etc.) I would look at creating worker
threads/processes for each plan node
Mariposa was an interesting cost-based distributed query engine based
upon PostgreSQL.
Perhaps that study may prove valuable insights.
http://epoch.cs.berkeley.edu:8000/mariposa/
---(end of broadcast)---
TIP 8: explain analyze is your friend
Marc == Marc G Fournier [EMAIL PROTECTED] writes:
Marc On Thu, 7 Oct 2004, Bruce Momjian wrote:
Added to TODO:
* Consider parallel processing a single query
This would involve using multiple threads or processes to do
optimization, sorting, or execution of
IMHO the best references to parallelizing query plans are in the
Volcano papers. The Exchange operator is a really clean abstraction -
the idea is to place the Exchange operator in query plans and that way
you don't have to paralellize any other operator. Exchange takes care
of managing the IPC
:[EMAIL PROTECTED] On Behalf Of
Sailesh Krishnamurthy
Sent: Friday, October 08, 2004 5:00 PM
To: Mike Rylander
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] APR 1.0 released
IMHO the best references to parallelizing query plans are in
the Volcano papers. The Exchange operator is a really
Added to TODO:
* Consider parallel processing a single query
This would involve using multiple threads or processes to do optimization,
sorting, or execution of single query. The major advantage of such a
feature would be to allow multiple CPUs to work together to process a
single
Any chance of having query parallelization added to TODO? I'm guessing
it will be a huge job, but it's also one of the places where the 'big 3'
have a huge advantage in scalability.
On Mon, Sep 13, 2004 at 10:24:05AM -0700, Sailesh Krishnamurthy wrote:
CB == Christopher Browne [EMAIL PROTECTED]
CB == Christopher Browne [EMAIL PROTECTED] writes:
CB futile discussions ask for it. Notably, on an SMP system, it
CB would be a neat idea for complex queries involving joins to
CB split themselves so that different parts run in separate
CB threads.
You don't really need
Well, it's easily changed, if all that's needed is a search-and-replace.
Suggestions for a better name?
MINGW32
I think that is a bad idea. That symbol sure suggests, that you are using mingw.
Are you expecting someone who creates a VisualStudio project to define
MINGW32 ?
Andreas
Bruce Momjian schrieb:
Andrew Dunstan wrote:
Reini Urban wrote:
FYI: WIN32 is also defined because windows.h is included.
(/usr/incluse/w32api/windef.h)
If you want this or that, do proper nesting, and use #else.
Ugh, yes. A little experimentation shows that __WIN32__ is defined for
MinGW
OK, moved and comment documents its location.
---
Reini Urban wrote:
Bruce Momjian schrieb:
Andrew Dunstan wrote:
Reini Urban wrote:
FYI: WIN32 is also defined because windows.h is included.
Reini Urban wrote:
Bruce Momjian schrieb:
OK, care to submit a patch. As I remember the fix for rename/unlink
also includes how the file is opened with flags. Anyway, we spent a lot
of time on this so you will have to go back in the archvies to find it
and determine how it can be
Bruce Momjian schrieb:
Reini Urban wrote:
Bruce Momjian schrieb:
OK, care to submit a patch. As I remember the fix for rename/unlink
also includes how the file is opened with flags. Anyway, we spent a lot
of time on this so you will have to go back in the archvies to find it
and determine how it
Personally I don't think that any rename()-usleep loop is necessary.
I'll check the archives.
I agree the rename loop seems unnecessary. I kept it in case we hadn't
dealt with all the failure places. Should we remove them now or wait
for 8.1? Seems we should keep them in and see if we
Bruce Momjian wrote:
Andrew Dunstan wrote:
I'm not sure exactly what Bruce checked, so I just spent a few cycles
making sure that we did not inadvertantly pick up a define of WIN32 from
windows.h anywhere else. I *think* we are OK on that. However, ISTM this
is a foot just waiting to be
Andrew Dunstan schrieb:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I'm not sure exactly what Bruce checked, so I just spent a few cycles
making sure that we did not inadvertantly pick up a define of WIN32
from windows.h anywhere else. I *think* we are OK on that. However,
ISTM this is a foot
Reini Urban wrote:
Andrew Dunstan schrieb:
We
had lots of Cygwin-specific defines in there already so Win32 just
means
both Mingw and Cygwin. You will see only a few cases where we want
Mingw and not Cygwin, but in those case we often also want MSVC and
Borland, so it really is WIN32 !
Zeugswetter Andreas SB SD wrote:
Personally I don't think that any rename()-usleep loop is necessary.
I'll check the archives.
I agree the rename loop seems unnecessary. I kept it in case we hadn't
dealt with all the failure places. Should we remove them now or wait
for 8.1?
Andrew Dunstan [EMAIL PROTECTED] writes:
Bottom line - this is something of a mess. If we can make sure Cygwin
isn't broken, we can probably live with what have for now. Personally, I
would have configure work out something cleaner, like, say, defining
WINDOWS_ALL for both Windows native
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Bottom line - this is something of a mess. If we can make sure Cygwin
isn't broken, we can probably live with what have for now. Personally, I
would have configure work out something cleaner, like, say, defining
WINDOWS_ALL for both
Andrew Dunstan wrote:
I agree that this is a good idea, partly because I do not care for the
assumption that MINGW is the only compilation environment we'll ever
support for the Windows-native port.
I'm not in a position to work out or test the required changes, but I'll
be happy to apply a
pgman wrote:
Andrew Dunstan wrote:
I think Bruce was mostly trying to make all the similar tests look
alike. Also I agree that if a !b is clearer than if !b a;
the latter requires a bit more thought to parse the extent of the !
operator...
Right, just consistency.
OK, change made. Thanks.
---
Most of the ~300 cases are ok for CYGWIN. And probably for MINGW also.
But I don't do MINGW countertests. I assume you do :)
Just palloc misses some pending fixes for CYGWIN. cvs head
Bruce Momjian wrote:
OK, I am wrong above. Coding assumes WIN32 is only for port named
WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin
defined it at all. Are we sure it does in a header file?
The problem is that some pieces of Cygwin code include windows.h, which
it
Peter Eisentraut wrote:
Bruce Momjian wrote:
OK, I am wrong above. Coding assumes WIN32 is only for port named
WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin
defined it at all. Are we sure it does in a header file?
The problem is that some pieces of Cygwin code
Bruce Momjian wrote:
There are alot of windows.h includes:
... and most of them are redundant because it is already included via
c.h.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 2: you can get off
Peter Eisentraut wrote:
Bruce Momjian wrote:
There are alot of windows.h includes:
... and most of them are redundant because it is already included via
c.h.
Right, but we only include windows.h in Mingw. Does Cygwin need it?
--
Bruce Momjian|
Bruce Momjian schrieb:
Peter Eisentraut wrote:
Bruce Momjian wrote:
There are alot of windows.h includes:
... and most of them are redundant because it is already included via
c.h.
Right, but we only include windows.h in Mingw. Does Cygwin need it?
Not really, but it will be lot of new work,
Reini Urban wrote:
Bruce Momjian schrieb:
Peter Eisentraut wrote:
Bruce Momjian wrote:
There are alot of windows.h includes:
... and most of them are redundant because it is already included
via c.h.
Right, but we only include windows.h in Mingw. Does Cygwin need it?
Not really, but it will
Andrew Dunstan wrote:
Reini Urban wrote:
Bruce Momjian schrieb:
Peter Eisentraut wrote:
Bruce Momjian wrote:
There are alot of windows.h includes:
... and most of them are redundant because it is already included
via c.h.
Right, but we only include windows.h in
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
There are alot of windows.h includes:
... and most of them are redundant because it is already included
via c.h.
Right, but we only include windows.h in Mingw.
That has nothing to do with my point.
Does Cygwin need
Peter Eisentraut wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
There are alot of windows.h includes:
... and most of them are redundant because it is already included
via c.h.
Right, but we only include windows.h in Mingw.
That has nothing to do
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Marc G. Fournier) would
write:
On Sat, 4 Sep 2004, Gaetano Mendola wrote:
Hi all,
now that Apache Portable Runtime was release why don't
use it on Postgres?
Short question: why? what does it give us, other then potential
reliance
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't understand most of this patch. What difference does changing the
preprocessor test order make?
I think Bruce was mostly trying to make all the similar tests look
alike. Also I agree that if a !b
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not sure exactly what Bruce checked, so I just spent a few cycles
making sure that we did not inadvertantly pick up a define of WIN32 from
windows.h anywhere else. I *think* we are OK on that. However, ISTM this
is a foot just waiting to be shot
Tom Lane schrieb:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not sure exactly what Bruce checked, so I just spent a few cycles
making sure that we did not inadvertantly pick up a define of WIN32 from
windows.h anywhere else. I *think* we are OK on that. However, ISTM this
is a foot just
Andrew Dunstan wrote:
I think Bruce was mostly trying to make all the similar tests look
alike. Also I agree that if a !b is clearer than if !b a;
the latter requires a bit more thought to parse the extent of the !
operator...
Right, just consistency.
Ok. I understand
OK, care to submit a patch. As I remember the fix for rename/unlink
also includes how the file is opened with flags. Anyway, we spent a lot
of time on this so you will have to go back in the archvies to find it
and determine how it can be improved.
Your track record for Cygwin diagnosis isn't
Bruce Momjian schrieb:
OK, care to submit a patch. As I remember the fix for rename/unlink
also includes how the file is opened with flags. Anyway, we spent a lot
of time on this so you will have to go back in the archvies to find it
and determine how it can be improved.
Your track record for
Andrew Dunstan wrote:
Reini Urban wrote:
FYI: WIN32 is also defined because windows.h is included.
(/usr/incluse/w32api/windef.h)
If you want this or that, do proper nesting, and use #else.
Ugh, yes. A little experimentation shows that __WIN32__ is defined for
MinGW
Bruce Momjian said:
Andrew Dunstan wrote:
Reini Urban wrote:
FYI: WIN32 is also defined because windows.h is included.
(/usr/incluse/w32api/windef.h)
If you want this or that, do proper nesting, and use #else.
Ugh, yes. A little experimentation shows that __WIN32__ is defined
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't understand most of this patch. What difference does changing the
preprocessor test order make?
I think Bruce was mostly trying to make all the similar tests look
alike. Also I agree that if a !b is clearer than if !b a;
the latter requires a
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I don't understand most of this patch. What difference does changing the
preprocessor test order make?
I think Bruce was mostly trying to make all the similar tests look
alike. Also I agree that if a !b is clearer than if !b a;
Bruce Momjian schrieb:
I looked at the APR code to get some ideas for the Win32 port. Some of
the ideas were good, but in other places like rename they didn't do very
well we were better off doing it ourselves and getting it right.
I remember looking at their code to fix the rename/unlink while
Reini Urban said:
Bruce Momjian schrieb:
I looked at the APR code to get some ideas for the Win32 port. Some
of the ideas were good, but in other places like rename they didn't do
very well we were better off doing it ourselves and getting it right.
I remember looking at their code to fix
Andrew Dunstan schrieb:
Reini Urban said:
Bruce Momjian schrieb:
I looked at the APR code to get some ideas for the Win32 port. Some
of the ideas were good, but in other places like rename they didn't do
very well we were better off doing it ourselves and getting it right.
I remember looking at
Reini Urban wrote:
FYI: WIN32 is also defined because windows.h is included.
(/usr/incluse/w32api/windef.h)
If you want this or that, do proper nesting, and use #else.
Ugh, yes. A little experimentation shows that __WIN32__ is defined for
MinGW only, but WIN32 is for both. I wonder how we
Gaetano Mendola wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Gaetano Mendola [EMAIL PROTECTED] writes:
|I don't know if APR provide a spin lock mechanism,
|
|
| You don't even know that, but you're confident that we can
Gaetano Mendola wrote:
Hi all,
now that Apache Portable Runtime was release why don't
use it on Postgres?
Now that we have discovered the formula for green cheese, why don't we
remake the moon out of it?
cheers
andrew
---(end of broadcast)---
TIP
On Sat, 4 Sep 2004, Gaetano Mendola wrote:
Hi all,
now that Apache Portable Runtime was release why don't
use it on Postgres?
Short question: why? what does it give us, other then potential reliance
on another project to build ... ?
Marc G. Fournier Hub.Org Networking Services
Gaetano Mendola [EMAIL PROTECTED] writes:
now that Apache Portable Runtime was release why don't
use it on Postgres?
The sense of the question is backwards. Why *should* we use it?
regards, tom lane
---(end of
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
now that Apache Portable Runtime was release why don't
use it on Postgres?
The sense of the question is backwards. Why *should* we use it?
In order to avoid all the annoyance that someone else had in
write code portable. I mean, how much
Gaetano Mendola [EMAIL PROTECTED] writes:
Don't you think that use of APR could save time ?
No, because we've already *done* the work it would purport to save.
It would cost us work to adapt our code to sit on top of APR, and
it's not clear to me that we'd be getting anything for it.
IIRC, this
Gaetano Mendola wrote:
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
now that Apache Portable Runtime was release why don't
use it on Postgres?
The sense of the question is backwards. Why *should* we use it?
In order to avoid all the annoyance that someone else had in
write code
Christopher Browne wrote:
... And since APR isn't BSD licensed, that would probably cause a
problem.
They are changin license for APR and I'll be not surprised if they
adopth the BSD one.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 3: if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Gaetano Mendola [EMAIL PROTECTED] writes:
|I don't know if APR provide a spin lock mechanism,
|
|
| You don't even know that, but you're confident that we can throw away
| our spinlock work and use APR anyway. You're wasting our
On Sun, 5 Sep 2004, Gaetano Mendola wrote:
Christopher Browne wrote:
... And since APR isn't BSD licensed, that would probably cause a
problem.
They are changin license for APR and I'll be not surprised if they
adopth the BSD one.
Since Apache has developed their own license, and I've seen at
60 matches
Mail list logo
