Guillaume Smet [EMAIL PROTECTED] writes:
Another question is how we can be sure it doesn't happen again. The
easiest way to test this is probably to have a JDBC test testing this
exact feature in the future benchfarm. Any comment?
Yeah, the lack of any formal testing of the extended-Query
-hackers,
As I announced it a couple of months ago, apart from the boxes donated
to PostgreSQLFr (affected to the web team IIRC), Continuent also
donated 7 servers and a Gb/s switch to us for QA testing. It took some
time to set them up but they're now up and running and available.
These servers
On Tue, Apr 1, 2008 at 8:06 AM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, the lack of any formal testing of the extended-Query protocol
is a real problem. I'm not sure of a good fix, but it bears some
thinking about. Not only do we not have an automated way to notice
if we broke
On Tue, Apr 1, 2008 at 1:22 AM, Tom Lane [EMAIL PROTECTED] wrote:
Please do --- I have a lot of other stuff on my plate.
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 23, 2008 at 01:13:38PM +0100, Mathias Hasselmann wrote:
[...]
Avahi/Bonjour/DNS-SD support[1] is very important, for integrating
Postgresql with modern
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly acquiring/releasing the lock.
ANALYZE is a
On 31/03/2008, Stephen Frost [EMAIL PROTECTED] wrote:
Pavel,
Honestly, I havn't dug into the real patch all that deeply but I did
notice a few minor issues which I've listed out below. The bigger
question I have for this patch, however, is just how close is it to
PL/pgSQL? If the
On 1-Apr-08, at 6:25 AM, Michael Paesold wrote:
Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING patch
to ensure that parameter values were being provided to the planner,
it became painfully obvious that the planner wasn't actually
Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING patch
to ensure that parameter values were being provided to the planner,
it became painfully obvious that the planner wasn't actually *doing*
anything with them. For example
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote:
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
[...]
Sorry for a dumb question, but I couldn't figure that out from your
references [1]..[4]: does that mean
From the idle thoughts in the middle of the night department:
I don't know if this has come up before exactly, but is it possible that
we could get a performance gain from building multiple indexes from a
single sequential pass over the base table? If so, that would probably
give us a
On Tue, Apr 1, 2008 at 6:23 AM, Pavel Stehule [EMAIL PROTECTED] wrote:
I can't to say so plpgpsm is an dialect of plpgsql. Minimally there
are different parser. I am sure so supported functions can be shared,
but it's mean really dramatic changes in plpgsql code. I belive so
separated
On Tue, Apr 1, 2008 at 5:51 PM, Andrew Dunstan [EMAIL PROTECTED] wrote:
From the idle thoughts in the middle of the night department:
I don't know if this has come up before exactly, but is it possible that
we could get a performance gain from building multiple indexes from a
single
* Andrew Dunstan [EMAIL PROTECTED] [080401 08:22]:
From the idle thoughts in the middle of the night department:
I don't know if this has come up before exactly, but is it possible that
we could get a performance gain from building multiple indexes from a
single sequential pass over the
Please do --- I have a lot of other stuff on my plate.
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly acquiring/releasing the lock.
I have
Guillaume,
* Guillaume Smet ([EMAIL PROTECTED]) wrote:
These servers are available 24/7 to PostgreSQL QA and won't be used
for other purposes.
Awesome.
Concerning the second point, I wonder if it's not worth it to have a
very simple thing already reporting results as the development cycle
Does anyone know what the correct behaviour for a scroll cursor should be
when you've scrolled past the end ?
If you take this SQL for example :
create temp table sometab ( a integer);
insert into sometab values(1);
insert into sometab values(2);
insert into sometab values(3);
Andrew Dunstan wrote:
I don't know if this has come up before exactly, but is it possible that
we could get a performance gain from building multiple indexes from a
single sequential pass over the base table?
It is already implemented in pg_bulkload
Aidan Van Dyk wrote:
* Andrew Dunstan [EMAIL PROTECTED] [080401 08:22]:
From the idle thoughts in the middle of the night department:
I don't know if this has come up before exactly, but is it possible that
we could get a performance gain from building multiple indexes from a
single
Dave Cramer [EMAIL PROTECTED] writes:
Was the driver ever changed to take advantage of the above strategy?
Well, it's automatic as long as you use the unnamed statement. About
all that might need to be done on the client side is to use unnamed
statements more often in preference to named ones,
So if I write
conn.prepareStatement(select col from table where col like ?)
then setString(1,'hello%')
The driver will do
prepare foo as select col from table where col like $1
and then
execute foo('hello%')
this will take advantage of the strategy automatically ?
If so this should be
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right thing to do instead of repeatedly
Am 01.04.2008 um 13:14 schrieb Dave Cramer:
On 1-Apr-08, at 6:25 AM, Michael Paesold wrote:
Am 01.04.2008 um 01:26 schrieb Tom Lane:
While testing the changes I was making to Pavel's EXECUTE USING
patch
to ensure that parameter values were being provided to the planner,
it became
On Tue, 01 Apr 2008 16:06:01 +0200, Tom Lane [EMAIL PROTECTED] wrote:
Dave Cramer [EMAIL PROTECTED] writes:
Was the driver ever changed to take advantage of the above strategy?
Well, it's automatic as long as you use the unnamed statement. About
all that might need to be done on the client
On Tue, 2008-04-01 at 10:22 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it
Mike Aubury [EMAIL PROTECTED] writes:
ie - under postgresql it appears we've scrolled *past* the last row and need
an additional fetch to get back to our last row..
Why do you find that surprising? It seems to me to be symmetrical with
the case at the beginning of the table --- the cursor is
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Andrew Dunstan [EMAIL PROTECTED] [080401 08:22]:
I don't know if this has come up before exactly, but is it possible that
we could get a performance gain from building multiple indexes from a
single sequential pass over the base table?
I've not
Am Dienstag, den 01.04.2008, 12:02 + schrieb [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 09:35:56AM +0200, Mathias Hasselmann wrote:
Am Samstag, den 29.03.2008, 12:25 + schrieb [EMAIL PROTECTED]:
[...]
Sorry for a dumb question, but
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 10:22 -0400, Tom Lane wrote:
In the fourth, if we actually believed this was a problem we'd
need to redesign VACUUM too, as it does the same thing.
VACUUM waits until nobody else has the buffer pinned, so lock contention
is much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 01, 2008 at 05:07:31PM +0200, Mathias Hasselmann wrote:
[...]
Personally, I'be rather scared than delighted ;-)
So in data centers you don't even trust the machines in your broadcast
domain?
Kind of. Put it another way: never have
I have problems on how to debug PostgreSQL on Linux using GDB. I made
some changes to src/backend/utils/sort/tuplesort.c but it hangs while
performing run formation (where my changes are).
I configured it using
./configure --prefix=/usr/local/pgsql/8.3/ CFLAGS=-O0 -DTRACE_SORT
Manolo SupaMA wrote:
Hi.
I have problems on how to debug PostgreSQL on Linux using GDB. I made
some changes to src/backend/utils/sort/tuplesort.c but it hangs while
performing run formation (where my changes are).
I configured it using
./configure --prefix=/usr/local/pgsql/8.3/
Hi.
I have problems on how to debug PostgreSQL on Linux using GDB. I made some
changes to src/backend/utils/sort/tuplesort.c but it hangs while performing
run formation (where my changes are).
I configured it using
./configure --prefix=/usr/local/pgsql/8.3/ CFLAGS=-O0 -DTRACE_SORT
I have now managed to investigate why some conversions of the PostgreSQL CVS
repository to other formats are having trouble or are failing. Here, I am
looking at git-cvsimport in particular.
The problem appears to be that several tags around the time of PostgreSQL 7.1
are broken or
On Mon, Mar 31, 2008 at 07:18:43PM -0400, Korry Douglas wrote:
David Fetter wrote:
I'd like to take a whack at making set-returning functions
returning SETOF RECORD a little more fun to use. Let's imagine
that we have a table foo and a function returning SETOF RECORD that
can return foos.
.
* Peter Eisentraut [EMAIL PROTECTED] [080401 12:01]:
I have now managed to investigate why some conversions of the PostgreSQL CVS
repository to other formats are having trouble or are failing. Here, I am
looking at git-cvsimport in particular.
The problem appears to be that several
Peter Eisentraut [EMAIL PROTECTED] writes:
In the meantime, does anyone have more information about how this came about?
Marc's always done both the tagging and the tarball-making, so you'd
have to ask him about that. I believe he's made it more scripted over
the years, so this might reflect a
* Tom Lane [EMAIL PROTECTED] [080401 14:15]:
Peter Eisentraut [EMAIL PROTECTED] writes:
In the meantime, does anyone have more information about how this came
about?
Marc's always done both the tagging and the tarball-making, so you'd
have to ask him about that. I believe he's made it
In PostGIS, we have a problem, in that spatial operations are very
costly, CPUwise.
We have hit on a nifty enhancement recently, which was to recognize
that when processing multiple rows, in joins or with literal
argouments, for most functions of the form GeometryOperation(A, B), A
(or B) tended
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
Please see the attached patch. One change I made is to hold the SHARE lock
on the page while ANALYZE is reading tuples from it. I thought it would
be a right
Tom Lane [EMAIL PROTECTED] writes:
Mike Aubury [EMAIL PROTECTED] writes:
ie - under postgresql it appears we've scrolled *past* the last row and need
an additional fetch to get back to our last row..
Why do you find that surprising? It seems to me to be symmetrical with
the case at the
I looked into the complaint here
http://archives.postgresql.org/pgsql-bugs/2008-04/msg5.php
about 8.3 being a lot slower than 8.2. Apparently what he's
doing is sending a whole lot of INSERT commands in a single
query string. And, sure enough, 8.3 is a lot slower. The
oprofile output is,
Gregory Stark [EMAIL PROTECTED] writes:
What's implied by that but perhaps not clear is that it's easier to think of
cursors as being *between* rows rather than *on* rows. I'm not sure the
standard entirely adopts that model however.
That's an interesting way of thinking about it, but I think
Paul Ramsey [EMAIL PROTECTED] writes:
The optimized form gets cached and retrieved from a memory context.
Each time the function is run within a statement it checks the cache,
and sees if one of its arguments are the same as the last time around.
If so, it uses the prepared version of that
On Tue, 2008-04-01 at 15:34 +, [EMAIL PROTECTED] wrote:
I would really prefer a more loosely coupled system.
The functionality will be much the same. The implementation would be
more difficult and obscure and there would be more points of failure and
more things to configure, but it wouldn't
Thanks Tom,
Yes, we've discussed adding some kind of optional identity information
to the object, it remains a potential course of action.
Paul
On Tue, Apr 1, 2008 at 2:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Paul Ramsey [EMAIL PROTECTED] writes:
The optimized form gets cached and
Apologies if this gets duplicated - original seems to have been dropped
due to patch size - this time I am sending it gzipped.
cheers
andrew
Original Message
Subject:column level privileges
Date: Tue, 01 Apr 2008 08:32:25 -0400
From: Andrew Dunstan [EMAIL
sanjay sharma wrote:
Hello Heikki,
Although the solution could be implemented using views and
functions and I am implementing a reference application using
this approach but TDE can greatly reduce the design and maintenance
complexcity. It would also take care of data protection in
On Tue, 1 Apr 2008, Guillaume Smet wrote:
I wonder if it's not worth it to have a very simple thing already
reporting results as the development cycle for 8.4 has already started
(perhaps several pgbench unit tests testing various type of queries with
a daily tree)
The pgbench-tools
On Tue, 1 Apr 2008, Guillaume Smet wrote:
A good answer is probably to plan optional JDBC benchmarks in the
benchfarm design - not all people want to run Java on their boxes but
we have servers of our own to do so.
The original pgbench was actually based on an older test named JDBCbench.
* Greg Smith ([EMAIL PROTECTED]) wrote:
=4 cores, =8GB RAM, and =8 disks with a usable write-caching controller
in it.
hrmmm. So a DL385G2, dual-proc/dual-core with 16GB of ram and 8 SAS
disks with a Smart Array P800 w/ 512MB of write cache would be helpful?
I've got quite a few such
Andrew Dunstan wrote:
From the idle thoughts in the middle of the night department:
I don't know if this has come up before exactly, but is it possible that
we could get a performance gain from building multiple indexes from a
single sequential pass over the base table? If so, that
On Wed, Apr 2, 2008 at 2:05 AM, Greg Smith [EMAIL PROTECTED] wrote:
I'm not sure if all of those changes are net positive for PostgreSQL
though, they weren't last time I played with this.
I fixed most of the bugs of JDBCBench I found when I benchmarked
Sequoia a long time ago. Totally forgot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, April 01, 2008 14:06:09 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
In the meantime, does anyone have more information about how this came about?
Marc's always done both the tagging and
Guillaume,
I for one would be very interested in the JDBCBench code.
Dave
On 1-Apr-08, at 8:35 PM, Guillaume Smet wrote:
On Wed, Apr 2, 2008 at 2:05 AM, Greg Smith [EMAIL PROTECTED]
wrote:
I'm not sure if all of those changes are net positive for PostgreSQL
though, they weren't last time I
On Wed, Apr 2, 2008 at 1:53 AM, Greg Smith [EMAIL PROTECTED] wrote:
The pgbench-tools utilities I was working on at one point anticipated this
sort of test starting one day. You can't really get useful results out of
pgbench without running it enough times that you get average or median
On Tue, Apr 1, 2008 at 3:29 PM, Stephen Frost [EMAIL PROTECTED] wrote:
I'm almost done scripting up everything to load the TIGER/Line
Shapefiles from the US Census into PostgreSQL/PostGIS. Once it's done
and working I would be happy to provide it to whomever asks, and it
might be an
On Wed, Apr 2, 2008 at 2:53 AM, Dave Cramer [EMAIL PROTECTED] wrote:
I for one would be very interested in the JDBCBench code.
OK, I didn't make anything fancy, I just fixed the problem I
encountered when profiling Sequoia (I mostly used it as an injector).
I'll post the code tomorrow if I can
Toru SHIMOGAKI [EMAIL PROTECTED] wrote:
Andrew Dunstan wrote:
we could get a performance gain from building multiple indexes from a
single sequential pass over the base table?
It is already implemented in pg_bulkload
(http://pgbulkload.projects.postgresql.org/).
I think there are two
Hello Andrew,
When do you expect this patch to go in production and available for public use?
I would keep an eye for its release.
Sanjay Sharma Date: Tue, 1 Apr 2008 18:40:24 -0400 From: [EMAIL PROTECTED]
To: pgsql-hackers@postgresql.org Subject: [HACKERS] column level privileges
The earliest will be 8.4, which is many many months away.
It should be possible to produce a patch for 8.3 if you're interested.
cheers
andrew
sanjay sharma wrote:
Hello Andrew,
When do you expect this patch to go in production and available for
public use? I would keep an eye for its
I have updated the patch queue web page so that I can move related
threads into a single thread, and have done so for the remaining emails.
I have also improved the appearance using CSS markup.
The new Append to Message-ID currently is only possible for me but I
can give other access as needed.
Because of this:
variadic function, named params exist only as WIP and I see it for
next commit fest. I'll send new version in next months.
This has been saved for the next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
On Tue, 1 Apr 2008, Andrew Dunstan wrote:
I don't know if this has come up before exactly, but is it possible that we
could get a performance gain from building multiple indexes from a single
sequential pass over the base table?
It pops up regularly, you might even have walked by a
There isn't enough agreement to move some things from pgcrypto to the
core so this thread is being removed from the patch queue.
---
Bruce Momjian wrote:
I am not thrilled about moving _some_ of pgcrypto into the backend
65 matches
Mail list logo
