[EMAIL PROTECTED]
> [mailto:[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 pl
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 qu
> "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, sortin
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
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
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 usi
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
same IPC techniques that we us
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
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 t
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 query
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 PR
> "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
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
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.
>
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.
> Do
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.
> >>
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 b
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, whic
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| http://can
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:
>
> > 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 Cygw
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 s
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 d
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...
> > >>
> > >>
> >
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
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 <[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 nati
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
>
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 && ! __CYGW
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 jus
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 shot
> > 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 se
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
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 b
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 is included.
> >>>(/usr/incluse/w32api/
Bruce Momjian schrieb:
Andrew Dunstan wrote:
Reini Urban wrote:
FYI: WIN32 is also defined because 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 WIN3
> > 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
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.
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 wait
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
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
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 t
"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
Bruce Momjian said:
> Andrew Dunstan wrote:
>>
>>
>> Reini Urban wrote:
>>
>> >
>> >
>> > FYI: WIN32 is also defined because 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 th
Andrew Dunstan wrote:
>
>
> Reini Urban wrote:
>
> >
> >
> > FYI: WIN32 is also defined because 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
>
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 Cyg
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 1
Reini Urban wrote:
FYI: WIN32 is also defined because 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 missed that
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 th
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 cod
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 th
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
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 leas
-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 ti
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 po
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 p
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, th
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:
> 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 broadcast)-
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 (ht
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 8
Hi all,
now that Apache Portable Runtime was release why don't
use it on Postgres?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
62 matches
Mail list logo
