[EMAIL PROTECTED] (David Fetter) wrote:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
>
> WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
> SELEC
I'm trying to change all the walkers and mutators to have a more
strict prototype. I had to do this with lots of casts.
I don't really like the idea of having all those generic pointer
types (Node * and void *), but currently see no better way to deal
with it.
I attached the patch.
Kurt
Index
We reject the following query:
nconway=# create table abc (a int, b int, c int);
CREATE TABLE
nconway=# select distinct on (a) a, b, c from abc order by b, c, a;
ERROR: SELECT DISTINCT ON expressions must match initial ORDER BY
expressions
This works fine, of course:
nconway=# select distinct o
Hi Jun,
DBT-2 is a fair use implementation of the TPC-C (OLTP), if you're
familiar with that.
I have 14 drives attached through 1 megaraid raid controller, and 52
drives connected through 4 channels on 2 mylex raid controllers, all in
a raid-0 configuration. I am using LVM2 on both sets of drive
On Fri, 2003-12-12 at 14:00, Tom Lane wrote:
> Currently the no-table-contents-changes restriction keeps us from
> upgrading from versions older than 7.4 anyway (since type NUMERIC had its
> on-disk representation changed in 7.4). We could possibly upgrade 7.3
> databases that contain no NUMERIC c
Tom Lane wrote:
>Dave Smith <[EMAIL PROTECTED]> writes:
>
>
>>Why not go the other way.
>>1) Dump the schemas.
>>2) Initdb with the new schemas in a tmp PGDATA
>>3) backup the schemas in the current PGDATA
>>4) move the new schemas from the new db into the current one.
>>
>>
>
>This seems l
On Fri, 12 Dec 2003, Tom Lane wrote:
> Alternative thought: just recommend that if possible, people take
> a filesystem dump of their old PGDATA directory after stopping
> the old postmaster. This would be sufficient for retreating to
> the prior version if needed. It might or might not be slowe
Hi Nick,
Here are the results of the comparisons I said I would do.
no-hyperthreading:
http://developer.osdl.org/markw/dbt2-pgsql/282/
- metric 2288.43
- baseline
hyperthreading:
http://developer.osdl.org/markw/dbt2-pgsql/278/
- metric 1944.42
- 15
Dave Smith <[EMAIL PROTECTED]> writes:
> Why not go the other way.
> 1) Dump the schemas.
> 2) Initdb with the new schemas in a tmp PGDATA
> 3) backup the schemas in the current PGDATA
> 4) move the new schemas from the new db into the current one.
This seems like approximately the same thing exc
Why not go the other way.
1) Dump the schemas.
2) Initdb with the new schemas in a tmp PGDATA
3) backup the schemas in the current PGDATA
4) move the new schemas from the new db into the current one.
This means that doing an update you would only have to have space for
the system catalogs not t
Manfred Spraul <[EMAIL PROTECTED]> writes:
> One advantage of a seperate write and fsync call is better performance
> for the writes that are triggered within AdvanceXLInsertBuffer: I'm not
> sure how often that's necessary, but it's a write while holding both the
> WALWriteLock and WALInsertLoc
Matthew T. O'Connor wrote:
>On Fri, 2003-12-12 at 15:42, Tom Lane wrote:
>
>
>>Alternative thought: just recommend that if possible, people take
>>a filesystem dump of their old PGDATA directory after stopping
>>the old postmaster. This would be sufficient for retreating to
>>the prior version
On Fri, 2003-12-12 at 15:42, Tom Lane wrote:
> Alternative thought: just recommend that if possible, people take
> a filesystem dump of their old PGDATA directory after stopping
> the old postmaster. This would be sufficient for retreating to
> the prior version if needed. It might or might not b
Bruce Momjian wrote:
write 0.000360
write & fsync 0.001391
write, close & fsync 0.001308
open o_fsync, write0.000924
That's 1 milliseconds vs. 1.3 milliseconds. Neither value is realistic -
I guess the hw cache on and the os doesn't issue cache flush command
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> On Fri, 2003-12-12 at 14:51, Andrew Dunstan wrote:
>> Maybe use an option which you would disable on Windows to copy the files
>> instead of hardlinking them.
> I think this would be a good feature even without hard link problems.
> If I am a p
Matthew T. O'Connor wrote:
On Fri, 2003-12-12 at 14:51, Andrew Dunstan wrote:
re Windows: pipes, yes, hard links, no (and no sane symlinks either)
Actually, NTFS does support hard links, there is just no support for it
in any MS file management GUI.
http://msdn.microsoft.com/library/defau
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Then again, in the case of pg_upgrade, wouldn't just disabling access from
> anywhere except localhost prevent others from getting in?
Not if your normal operating mode includes connections from clients
running locally. I really don't see any clean
On Fri, 12 Dec 2003, Peter Eisentraut wrote:
> Tom Lane wrote:
> > I think it's important to be able to run pg_upgrade with the
> > postmaster shut down. Otherwise there is too much risk that some
> > other user will change the database while we are working. The
> > original pg_upgrade script le
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Instead, all operations should be done through a standalone backend.
> This would also be a nice solution for people who want a standalone,
> server-less database system. But for the purpose of pg_upgrade it
> seems like a lot o
On Fri, 2003-12-12 at 14:51, Andrew Dunstan wrote:
> re Windows: pipes, yes, hard links, no (and no sane symlinks either)
Actually, NTFS does support hard links, there is just no support for it
in any MS file management GUI.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfile
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> re Windows: pipes, yes, hard links, no (and no sane symlinks either) -
> also of course no (sane) shell - is this going to be a script or a C
> program?
C, certainly.
> Maybe use an option which you would disable on Windows to copy the files
> inste
re Windows: pipes, yes, hard links, no (and no sane symlinks either) -
also of course no (sane) shell - is this going to be a script or a C
program?
Maybe use an option which you would disable on Windows to copy the files
instead of hardlinking them. Yes it would take lots more time and space,
Tom Lane wrote:
> I think it's important to be able to run pg_upgrade with the
> postmaster shut down. Otherwise there is too much risk that some
> other user will change the database while we are working. The
> original pg_upgrade script left it to the DBA to ensure this wouldn't
> happen, but t
In article <[EMAIL PROTECTED]> you wrote:
> On Fri, Dec 12, 2003 at 10:13:56AM -0800, David Fetter wrote:
>
>> I'm looking to the SQL WITH clause as a way to get better regex
>> support in PostgreSQL. I've been chatting a little bit about this,
>> and here's an idea for a behavior. Implementatio
On Thu, 11 Dec 2003, Dave Page wrote:
> > "Dave Page" <[EMAIL PROTECTED]> writes:
> > > gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> > > -Wmissing-declarations prod -I../../src/include -D_GNU_SOURCE
> > > -I/usr/include -c -o path.o path.c
> > > gcc: cannot specify -o with -c or -S
On Fri, Dec 12, 2003 at 10:13:56AM -0800, David Fetter wrote:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
I think you could be rather looki
I am planning to solve the ancient problem of updating to a new major
version without dump/reload, by means of writing a new, more bulletproof
implementation of Bruce's old pg_upgrade script. Here are some design
notes --- please comment.
The upgrade scenario
I envision the
On Fri, Dec 12, 2003 at 07:47:26PM +0100, Peter Eisentraut wrote:
> David Fetter wrote:
> > I'm looking to the SQL WITH clause as a way to get better regex
> > support in PostgreSQL. I've been chatting a little bit about
> > this, and here's an idea for a behavior. Implementation details
> > TBD.
David Fetter <[EMAIL PROTECTED]> writes:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
> WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
> SELEC
David Fetter wrote:
> I'm looking to the SQL WITH clause as a way to get better regex
> support in PostgreSQL. I've been chatting a little bit about this,
> and here's an idea for a behavior. Implementation details TBD.
>
> WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
> SELECT *
> FROM x
> WHERE
Kind people,
I'm looking to the SQL WITH clause as a way to get better regex
support in PostgreSQL. I've been chatting a little bit about this,
and here's an idea for a behavior. Implementation details TBD.
WITH res = match (x.foo, '([0-9]+)x([0-9]+)')
SELECT *
FROM x
WHERE y = res[2]
ORy =
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> IIRC we don't copy anything but plain files and directories - no special
> files, symlinks or fifos, so the -R/-r differences shouldn't affect us
> anyway, should they? Also, that should make the implementation of an
> internal recursive copy much sim
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
but my BSD/OS manual only documents 'cp -R' and mentions:
I think we should switch to -R in our code.
And break the code on who knows how many other systems? No thanks.
If we want to do anything at all with this code, we should el
Peter Eisentraut wrote:
> Tom Lane wrote:
> > libpq++ got heaved overboard largely
> > because the autoconf burden for it was too high,
>
> That's news to me. Certainly the overhead doesn't grow smaller by
> splitting stuff up in smaller pieces.
Yea, now there is no configure for libpq++ at all
Bruce Momjian <[EMAIL PROTECTED]> writes:
> but my BSD/OS manual only documents 'cp -R' and mentions:
> I think we should switch to -R in our code.
And break the code on who knows how many other systems? No thanks.
If we want to do anything at all with this code, we should eliminate the
use of s
> Running the attached test program shows on BSD/OS 4.3:
>
> write 0.000360
> write & fsync 0.001391
I think the "write & fsync" pays for the previous "write" test (same filename).
> write, close & fsync 0.001308
> open o_fsync, write0.000
The sqlstandards.org is still down I think. Is this something new in the
upcoming 200x spec? I could not see it mentioned in the SQL-99.
I'm a great fan of standards. If there is one I'll make my pljava adhere to
it. Any information on this topic is greatly appreciated.
Thanks,
- thomas
"Peter
37 matches
Mail list logo
