Hi,
I asked about this before, but the thread got hijacked to discuss
another buildfarm failure :-(. Currently our only Windows Vista
buildfarm member (Vaquita) fails every time (assuming it gets that far)
on ECPG's dt_test and update tests.
I've checked the FS permissions, and see no
Are you filling multiple buffers in the buffer cache with a single
read-call?
yes, needs vector or ScatterGather IO.
I would expect that to get only moderate improvement.
The vast improvement comes from 256k blocksize.
To get
the full benefit I would think you would want to
Marshall, Steve [EMAIL PROTECTED] wrote:
the first query would be optimized using
constraint exclusion, while the second query would not:
SELECT * FROM test_bulletins WHERE created_at '2006-09-09
05:00:00+00'::timestamptz;
SELECT * FROM test_bulletins WHERE created_at '2006-09-09
On Wed, May 09, 2007 at 09:21:59AM +0100, Dave Page wrote:
I asked about this before, but the thread got hijacked to discuss
another buildfarm failure :-(. Currently our only Windows Vista
buildfarm member (Vaquita) fails every time (assuming it gets that far)
on ECPG's dt_test and update
On Tue, 2007-05-08 at 11:40 +0100, Heikki Linnakangas wrote:
Here's my roadmap for the scan-resistant buffer cache and
synchronized scans patches.
1. Fix the current vacuum behavior of throwing dirty buffers to the
freelist, forcing a lot of WAL flushes. Instead, use a backend-private
Michael Meskes wrote:
Dave, could you please run
insert into date_test ( d , ts ) values ( date '1966-01-17' ,
timestamp '2000-07-12 17:34:29' );
on the Vista system and then select * from date_test;?
According to the logs the insert runs successfully but the select gives
an invalid date
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test results.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Peter Eisentraut wrote:
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test results.
And that helps us how exactly, on what will probably be the most widely
used OS in the world within a few
Peter Eisentraut wrote:
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test results.
Not doing this would seem like sheer bloody-mindedness. We have
workarounds for craziness on
On 5/9/2007 7:46 AM Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the more
basic checks they use is the filename - *anything* called setup.exe will
cause user confirmation to be required
Ned Lilly wrote:
On 5/9/2007 7:46 AM Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the
more basic checks they use is the filename - *anything* called
setup.exe will cause user
On Wed, May 09, 2007 at 08:40:24AM -0400, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Am Mittwoch, 9. Mai 2007 13:46 schrieb Dave Page:
Can we rename the test please?
I'm thinking no. Brain-dead systems should produce brain-dead test
results.
Not doing this would
Hello,
first of all, I've tried to ask on pgsql-general mailing list as advised,
but no answer.
I'd like to look at a possibility of integrating OpenPMF
(http://www.openpmf.org) with the PostgreSQL. There is a possibility to
have a weak integration by using a provided rule system and SQL,
Karel Gardas wrote:
Hello,
first of all, I've tried to ask on pgsql-general mailing list as advised,
but no answer.
I'd like to look at a possibility of integrating OpenPMF
(http://www.openpmf.org) with the PostgreSQL. There is a possibility to
have a weak integration by using a provided
On May 8, 2007, at 2:24 PM, Magnus Hagander wrote:
Speaking of which, it might be interesting to actually show these
values
in the stats collector. I was thinking three cols for each database
(probably the best level?) that counts each of those three
counters. If
you have a lot of sorts
On Wed, May 09, 2007 at 10:55:12AM -0500, Jim Nasby wrote:
On May 8, 2007, at 2:24 PM, Magnus Hagander wrote:
Speaking of which, it might be interesting to actually show these
values
in the stats collector. I was thinking three cols for each database
(probably the best level?) that counts
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am having
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
Magnus Hagander [EMAIL PROTECTED] writes:
What 3 columns? In-memory sorts, on-disk sorts, and on-disk size?
(Sum of how much spilled to disk).
I was thinking in-mem sorts, on-disk sorts, limited-by-LIMIT sorts (that
would be the new feature..)
Tom's code distinguished in-memory, top-N,
Jim,
I am sympathetic to the issues you and Andrew are describing (I
understand Bruce's stream analogy, but I think Andrew is right that
from the user's point of view, it's not usable). But I am not
convinced that users voting on desired features will get us the
users' desired features. The
Hi there,
I'm investigating a problem my client experienced with
create database xxx with template=yyy - they often get error
ERROR: source database yyy is being accessed by other users,
I modelled situation in clean environment with very simple perl script
( FreeBSD 6.2-STABLE,
Oleg Bartunov [EMAIL PROTECTED] writes:
I'm investigating a problem my client experienced with
create database xxx with template=yyy - they often get error
ERROR: source database yyy is being accessed by other users,
Your test case simply shows that it takes a finite amount of time for
the
Tom Lane wrote:
Your test case simply shows that it takes a finite amount of time for
the previous backend to exit; depending on scheduler priorities it's
possible for the next instance to connect and try to CREATE DATABASE
before the previous one is gone. My suggestion would be to connect
to
[cc'ing to pgsql-hackers since this is looking like a contrib/intarray bug]
Valentine Gogichashvili [EMAIL PROTECTED] writes:
here is the DT
That works fine for me in 8.2:
regression=# explain SELECT id, (myintarray_int4)
FROM myintarray_table_nonulls
WHERE ARRAY[8] @ myintarray_int4;
On Wed, 9 May 2007, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
I'm investigating a problem my client experienced with
create database xxx with template=yyy - they often get error
ERROR: source database yyy is being accessed by other users,
Your test case simply shows that it
Oleg Bartunov [EMAIL PROTECTED] writes:
I tried that connecting to template1, but it doesn't helped. The problem
occurs even if I repeat 'drop;create' in one connection (the same backend).
Hmm. Do you have autovacuum turned on? 8.2 isn't real smart about
dealing with autovac running in the
Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
What 3 columns? In-memory sorts, on-disk sorts, and on-disk size?
(Sum of how much spilled to disk).
I was thinking in-mem sorts, on-disk sorts, limited-by-LIMIT sorts (that
would be the new feature..)
Tom's code
On Wed, 9 May 2007, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
I tried that connecting to template1, but it doesn't helped. The problem
occurs even if I repeat 'drop;create' in one connection (the same backend).
Hmm. Do you have autovacuum turned on? 8.2 isn't real smart about
After some more study of the SQL spec, the distinction between GENERATED
ALWAYS AS IDENTITY and GENERATED BY DEFAULT AS IDENTITY is not what
I thought it was.
* As far as I can find from the spec, there is *no* difference between
the two cases for INSERT commands. The rule is that you ignore any
Magnus Hagander wrote:
Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
What 3 columns? In-memory sorts, on-disk sorts, and on-disk size?
(Sum of how much spilled to disk).
I was thinking in-mem sorts, on-disk sorts, limited-by-LIMIT sorts (that
would be the new feature..)
On May 9, 2007, at 11:01 AM, Magnus Hagander wrote:
On Wed, May 09, 2007 at 10:55:12AM -0500, Jim Nasby wrote:
On May 8, 2007, at 2:24 PM, Magnus Hagander wrote:
Speaking of which, it might be interesting to actually show these
values
in the stats collector. I was thinking three cols for each
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am
Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be
Folks,
While trying to test the arrays of complex types, I used a
stripped-down configure. Too stripped down, it turns out.
CFLAGS=-O0 ./configure --prefix=/var/lib/pgsql/tip --with-pgport=2225
--enable-cassert --enable-debug --enable-depend --enable-integer-datetimes
I set $PGDATA to my
Hi,
In reference to the seq scans roadmap, I have just submitted a patch
that addresses some of the concerns.
The patch does this:
1. for small relation (smaller than 60% of bufferpool), use the
current logic
2. for big relation:
- use a ring buffer in heap scan
- pin
Hiroshi Inoue [EMAIL PROTECTED] writes:
Robert Treat wrote:
It's generally a very bad idea for a BSD licensed project to include lgpl
licensed code
Psqlodbc package is LGPL licensed and seems to have little problem to
include copy of BSD licensed code as a part of it.
Right, that direction
David Fetter [EMAIL PROTECTED] writes:
It turns out that PL/PerlU wasn't available, even though createlang
had succeeded. I think this is a bug in CREATE LANGUAGE, as CREATE
LANGUAGE should have failed when it found no PL/Perl compiled in.
Works for me:
$ createlang plperlu array_test
37 matches
Mail list logo
