Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Where are we going to find a representative test set of
>> dozen-or-more- way SQL join queries?
> As far as getting good lotsa-join queries, I think we can either:
>(1) generate the queries programmatically
>
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> The latter is a really bad idea IMHO. The io_in_progress lock can be
>> held for eons (in CPU terms) and should not be blocking people who
>> simply want to bump their refcount up and down.
> My reasoning was that t
Tom Lane <[EMAIL PROTECTED]> writes:
> Where are we going to find a representative test set of
> dozen-or-more- way SQL join queries?
Interesting that you should mention that. I've been thinking for a
while that we need a much more extensive test suite for the query
optimizer. This would allow us
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> AFAIK the only target build environment for Windows right now is MinGW/gcc
>>
>> If anyone knows how to get the M$ compilers to work nicely with our build
>> system that might be interesting, but probably at a later stage.
> MS
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I'm assuming that the original author of the GEQO code already did
>> that testing ...
> Removing the code without bothering to verify this assumption is a
> little unwise, IMHO:
Fair enough. I did a little bit of
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > On Monday 05 January 2004 12:51, Peter Eisentraut wrote:
> >> Jean-Eric Cuendet wrote:
> >>> - User permissions based on columns?
> >
> >> Well, I have about half a patch for column privileges lying around, but
> >> I've never had eno
Claudio Natoli wrote:
>
>
> Tom Lane writes:
> > [cvs is your friend...] It appears to have been added as part of the
> > MinGW porting work last May. I don't have much faith in it; as far as
> > I heard the MinGW port never got further than making the client-side
> > code work, and so this fil
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > Or, maybe we'll just use the tas() implementation that already exists for
> > __i386__/__x86_64__ in s_lock.h. How did I miss that?
> > Move along. Nothing to see here.
>
> Actually, I was expecting you to complain that the s_lock.h
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> I'm not sure there's any need for
> >> src/backend/port/win32/sema.c at all.
>
> > (Do you have any idea on the historical
> > context of this code? I wondered as to, if we have no win32 port, why there
> > woul
Andrew Dunstan wrote:
> Tom Lane said:
> >
> > Actually, I was expecting you to complain that the s_lock.h coding is
> > gcc-specific. Which compilers do we need to support on Windows?
> >
>
> AFAIK the only target build environment for Windows right now is MinGW/gcc
>
> If anyone knows how to g
Bruce Momjian <[EMAIL PROTECTED]> writes:
> On Monday 05 January 2004 12:51, Peter Eisentraut wrote:
>> Jean-Eric Cuendet wrote:
>>> - User permissions based on columns?
>
>> Well, I have about half a patch for column privileges lying around, but
>> I've never had enough motivation to do the other
Well, I have about half a patch for column privileges lying around, but
I've never had enough motivation to do the other, more complicated
half...
Is there a TODO and TODO.detail warrented here?
I thought views took care of this. Comments?
They're needed for SQL99 anyway I think.
Chris
---
Robert Treat wrote:
> On Monday 05 January 2004 12:51, Peter Eisentraut wrote:
> > Jean-Eric Cuendet wrote:
> > > - User permissions based on columns? (Ex: User1 has Select on Column
> > > "CompayName" but User2 has update on column "CompanyName" while User3
> > > has create new row on table).
> >
Tom Lane wrote:
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > One important thing I forgot, that someone could start looking at now:
> > * backends keeping files open when other backends are trying to
> > delete/rename them
>
> > We must do better for the official port,
>
> Why? The proce
I have spent the past 10 days doing work for SRA, my employer, and
attending LinuxWorld in New York City. Our BOF was well attended, with
35 people, and there were a lot of good PostgreSQL usage reports at the
event. I have told people to post their news items to the web site or
advocacy.
I have
Claudio Natoli <[EMAIL PROTECTED]> writes:
> One important thing I forgot, that someone could start looking at now:
> * backends keeping files open when other backends are trying to
> delete/rename them
> We must do better for the official port,
Why? The procedure you mentioned seems perfectly
On Jan 21, 2004, at 12:19 PM, Peter Eisentraut wrote:
I think "output XML" is just buzz. Give us a real use scenario and an
indication that a majority also has that use scenario (vs. the other
ones listed above), then we can talk.
I do this all the time.
I have JDBC code to take a java.sql.Result
> Might I just suggest good old "C:\PostgreSQL" ?
>
> MS SQL server defaults to C:\MSSQL, so I don't think that a directory in
the
> root path is unreasonable. Further, it makes it look more important if it
> installs in the root directory :)
Don't do that. I hate software that does that. To me
Some fool wrote:
> It will then be a matter of fixing things like:
> * installation directory issues (/usr/local/pgsql/bin won't work too
>well outside of the MingW environment :-)
> * general directory handling (ie. whitespaces in directory names;
>forward/backslash path canonicalizatio
> Where can I get the latest tarball for Win32 development?
There isn't a specific Win32 tarball, but you can get nightly snapshots from
the usual place (ftp://ftp.postgresql.org/pub/dev/), or pull down the tip
from CVS.
Reading back through the thread though, you'll find that the code is not y
I needed these, so I went and implemented them myself. I have to admit
I'm not so wise on PostgreSQL backend stuff, and so I abstained from
editing the fmgrtab.c and postgres.bki.
Sorry for that, but it just seemed too complicated. Perhaps there
should really be a script to do this? I could ima
> -Original Message-
> From: Claudio Natoli [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 22, 2004 4:44 PM
> To: 'Andrew Dunstan '; 'pgsql-hackers-win32 ';
> 'PostgreSQL-development '
> Subject: Re: [pgsql-hackers-win32] [HACKERS] What's left?
>
>
>
> Andrew Dunstan wrote:
> > Cl
Hi all,
Might I just suggest good old "C:\PostgreSQL" ?
MS SQL server defaults to C:\MSSQL, so I don't think that a directory in the
root path is unreasonable. Further, it makes it look more important if it
installs in the root directory :)
All the best,
-David Felstead
Claudio Natoli wrote:
Andrew Dunstan wrote:
> Claudio Natoli wrote:
>
> > * installation directory issues (/usr/local/pgsql/bin won't work too
> > well outside of the MingW environment :-)
>
>
> Clearly we will need an installer for a binary distribution.
Yes. To be more precise, my point was that doing so will req
(Sorry Tom, I was meaning to reply to you once I'd had a chance to
revise the bufmgr patch; since that seems a fair ways off, I figured
it would be better to respond now.)
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> we now hold the buffer's meta data lo
Claudio Natoli wrote:
* installation directory issues (/usr/local/pgsql/bin won't work too well
outside of the MingW environment :-)
Clearly we will need an installer for a binary distribution. But for now
I suggest that the default prefix on Windows is
C:\Program Files\PostgreSQL
cheers
andr
> I would like very much to help any way possible in solving any last
> remaining issues. Once the CVS sources are compliable, it will be
> easier to make meaningful contributions. I'm really looking
> forward to testing and benchmarking the win32 port. A big thanks
> to all who continue to w
Tom Lane <[EMAIL PROTECTED]> writes:
> I'm assuming that the original author of the GEQO code already did
> that testing ...
Removing the code without bothering to verify this assumption is a
little unwise, IMHO: given the low quality of the rest of the GEQO
code, I wouldn't be surprised to learn
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> The current thought is to add some sort of hook that allows a
> user-defined action to be taken at the point where a WAL file
> would normally get recycled. Presumably this action would
> involve copying the WAL file to someplace else (eg a t
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> On Thu, 22 Jan 2004, Tom Lane wrote:
>> I'm assuming that the original author of the GEQO code already did that
>> testing ...
> Hmmm. I was figuring he wasn't sure so he left them in for other people
> to test. Is this a part of the code that eats
On Thu, 22 Jan 2004, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > On Wed, 21 Jan 2004, Tom Lane wrote:
> >> The GEQO planner module contains six different recombination algorithms,
>
> > considering the recent discussion about REALLY slow query planning by the
> > GEQO modul
Jean-Michel POURE said:
>
> Morphix could be a possible solution to the MS Windows migration
> problems. It probably involves 50 times less work than migrating
> PostgreSQL to MS Windows (and is a complete different project except
> for the fact that it could well bring as much new users to Post
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> On Wed, 21 Jan 2004, Tom Lane wrote:
>> The GEQO planner module contains six different recombination algorithms,
> considering the recent discussion about REALLY slow query planning by the
> GEQO module, it might be worth testing each one to see which
Jan Wieck <[EMAIL PROTECTED]> writes:
> While talking about it, I think our usage of signals is way overloaded
> anyway. Any ideas how to replace it all with just one signal and a
> regular message queue?
Fooling with the definitions of SIGTERM, SIGINT, SIGQUIT would be a
really bad idea, since
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Any comments?? Takers?
Um, did you read the discussion of the ARC buffer management algorithm
that's already been implemented for 7.5?
The main objection I have to doing it Oracle's way is that that creates
more parameters that DBAs have to get right fo
On Wed, 21 Jan 2004, Tom Lane wrote:
> The GEQO planner module contains six different recombination algorithms,
> only one of which is actually used --- the others are ifdef'd out, and
> have been ever since we got the code. Does anyone see a reason not to
> prune the deadwood?
considering the r
Simon,
have you read src/backend/storage/buffer/README of current CVS tip?
The algorithm in the new replacement strategy is an attempt to figure
that SMALL_TABLE_THRESHOLD automatically. Do you see anything that can
be improved in that algorithm?
Jan
Simon Riggs wrote:
This discussion seems
Dear friends,
In the past, there were several discussions in order to find suitable answers
for MS Windows users willing to install and run PostgreSQL.
Some of you suggested that users should "install GNU/Linux over Windows". Not
so easy for the basic MySQL or Ms Windows user, who need technica
Hello,
I think it's safe to say there is a working implementation of a signal
handler. The one tricky part left is to identify some smart places for
the backend to check the awaiting signal queue. The first one is easy:
switch recv() with select() with a reasonable timeout and a poll.
If and wh
Magnus Hagander wrote:
Hello!
The backend signals code today uses pqsignal() instead of signal() at
all places. But it uses kill() and sigsetmask() (through the macro
PG_SETMASK) directly.
I propose to change this to pqkill() and pqsigsetmask(). In pqsignal.h,
these would be #define:d back to kill
On Unix, the general rule for a shared library is to prepend "lib" and
append ".so". On Windows, nothing is prepended and you add ".dll". Thus for
a module named "pljava" you'd get:
libpljava.so on Unix and:
pljava.dll on Windows.
This is in fact so common that the Java Native Interface (JNI) use
This discussion seems likely to have a major effect on DBT-3 (DSS-type)
performance from PostgreSQL...
> On Fri, 16 Jan 2004, Michael Brusser wrote:
>
> > Is there a way to force database to load
> > a frequently-accessed table into cache and keep it there?
>
> Scott Marlow replied...
>
> Nope.
Hello!
The backend signals code today uses pqsignal() instead of signal() at
all places. But it uses kill() and sigsetmask() (through the macro
PG_SETMASK) directly.
I propose to change this to pqkill() and pqsigsetmask(). In pqsignal.h,
these would be #define:d back to kill() and setsigmask() fo
Dear Bruce:
Included is the abstract for my replication system I promised to you.
PGCluster is a replication system for PostgreSQL.
Features of PGCluster include:
- synchronized multi-master replication
- load balancing
- re-synchronizing database cluster which is in
lost-synchronization sta
44 matches
Mail list logo
