Is the intent to replace most uses of (pg)kill with a general
purpose messaging system between the processes, or
(just) to address notify per se?
(Presumably with 'fire-and-forget' and also rpc
semantics? And pub-sub? And some sort of
write to an fd protected by an atomic flag to
elide multiple
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 backen
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 discussion
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
---
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.
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 re
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> >
>
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 ther
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 c
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 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
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
-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 taggin
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 forg
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, th
* 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 ma
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.
That
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 utilitie
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
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 PROTE
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 an
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
"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
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 t
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, um,
"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 c
"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
>>
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 t
* 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'
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
.
* 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 seve
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
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 inconsisten
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/" CFLAGS="
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"
--enable-
-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 ha
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"
--enable-d
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 que
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
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
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
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 thoug
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 clie
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 ch
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 painfully
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
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
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
(http://pgbulkload.projects.postgresql.or
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);
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 cycl
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
* 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
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
> s
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 pote
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
> separate
-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
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 *doin
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
execut
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? I
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
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 mod
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
63 matches
Mail list logo
