Hi,
I wanted to do some transformation on an inet value from
an SPI-using function. The inet Datum passed from SPI_getbinval()
to the values array in heap_form_tuple() obviously gives good data
to the frontend. When I use DatumGetInetP() on the Datum,
the structure passed to me is corrupt:
On 08.11.2011 11:22, Boszormenyi Zoltan wrote:
Hi,
I wanted to do some transformation on an inet value from
an SPI-using function. The inet Datum passed from SPI_getbinval()
to the values array in heap_form_tuple() obviously gives good data
to the frontend. When I use DatumGetInetP() on the
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 8, 2011 at 2:54 AM, Robert Haas robertmh...@gmail.com wrote:
It would still be nice to fix the case where we need to freeze a tuple
that is on a page someone else has pinned, but I don't have any good
ideas
I ran into a performance problem described in this thread:
http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
continued here:
http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
OpenSSL compresses data by default, and that causes a
performance penalty of 100%
Excerpts from Robert Haas's message of mar nov 08 01:25:31 -0300 2011:
But I can't help feeling that as we continue to add more features,
we've eventually going to end up with our backs to the wall. Not sure
what to do about that, but...
What I've imagined for a long time is psql being able
On Tue, Nov 8, 2011 at 1:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please continue to expect that, I just haven't finished it yet...
OK.
So here's the deal: this is an effective, mostly automatic solution to
the performance problem noted in the original post. For example, at
32 clients,
On Tue, Nov 8, 2011 at 14:59, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I ran into a performance problem described in this thread:
http://archives.postgresql.org/pgsql-performance/2011-10/msg00249.php
continued here:
http://archives.postgresql.org/pgsql-performance/2011-11/msg00045.php
On 11/08/2011 03:59 PM, Albe Laurenz wrote:
If there are concerns about that, maybe a GUC variable like
ssl_compression (defaulting to off) would be a solution.
I'd vote for a libpq connect option instead. Something like
sslcompress=yes|no accompanied by PGSSLCOMPRESS environment
variable.
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network connections, but is that
a realistic scenario?
Yes, it's a realistic scenario.
Marko Kreen mark...@gmail.com writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network connections, but is that
a realistic
On Tue, Nov 8, 2011 at 2:24 AM, YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
latestCompletedXid got backward due to concurrent updates
and it fooled TransactionIdIsInProgress?
Ah ha! I bet that's it.
I think this could be avoided by a more sophisticated locking scheme.
Instead of waking up
On Tue, Nov 8, 2011 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The fact of the matter is that in most situations where you want SSL,
ie links across insecure WANs, compression is a win. Testing a local
connection, as you seem to have done, is just about 100% irrelevant to
performance in
On 11/08/2011 09:34 AM, Tom Lane wrote:
Marko Kreenmark...@gmail.com writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenzlaurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data over really slow network
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2011 09:34 AM, Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
default. But before adding YA connection option, I'd want to see some
On Tue, Nov 8, 2011 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2011 09:34 AM, Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
On Tue, Nov 8, 2011 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On Tue, Nov 8, 2011 at 3:59 PM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
It is possible that this could cause a performance
regression for people who SELECT lots of compressible
data
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, it seems to be intentional, but I agree it's very much contrary to
the usual convention that DatumGetXXXP() returns a detoasted and
depacked datum. I think we should change it. I propose the attached
patch. It changes
On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas robertmh...@gmail.com wrote:
But there's an efficiency argument against doing it that way. First,
if we release the pin then we'll have to reacquire the buffer, which
means taking and releasing a BufMappingLock, the buffer header
spinlock, and the
2011/11/8 Alvaro Herrera alvhe...@commandprompt.com:
What I've imagined for a long time is psql being able to display each
row in more than one line; for example something like
\df
Listado de funciones
Esquema | Nombre | Tipo de dato de salida | Tipo
On Tue, Nov 8, 2011 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Nov 8, 2011 at 1:50 PM, Robert Haas robertmh...@gmail.com wrote:
But there's an efficiency argument against doing it that way. First,
if we release the pin then we'll have to reacquire the buffer, which
means
Tom Lane wrote:
I distinctly recall us getting bashed a few years ago because there
wasn't any convenient way to turn SSL compression *on*. Now that SSL
finally does the sane thing by default, you want to turn it off?
The fact of the matter is that in most situations where you want SSL,
ie
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 8, 2011 at 2:26 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think we need to avoid long pin hold times generally.
In the case of a suspended sequential scan, which is the case where
this has most recently bitten me on a production
Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011:
Isn't that what pagers like 'less' and 'more' do already? May be we
could provide a pager more specific to psql output as a contrib or
extension.
Well, now that you mention it, all pagers I know are line-based. If
On Tue, Nov 8, 2011 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It strikes me that the only case where vacuum now has to wait is where
it needs to freeze an old XID. Couldn't it do that without insisting on
exclusive access? We only need exclusive access if we're going to move
data
Robert Haas robertmh...@gmail.com writes:
Interesting idea. I think in general we insist that you must have a
buffer content lock to inspect the tuple visibility info, in which
case that would be safe. But I'm not sure we do that absolutely
everywhere. For instance, just last night I
Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
default. But before adding YA connection option, I'd want to see some
evidence that it's useful over non-local connections.
Here are
On Tue, Nov 08, 2011 at 04:59:02PM +0100, Albe Laurenz wrote:
Tom Lane wrote:
There might be some argument for providing a client option to disable
compression, but it should not be forced, and it shouldn't even be the
default. But before adding YA connection option, I'd want to see some
On Tue, Nov 08, 2011 at 04:19:02PM +0100, Albe Laurenz wrote:
Tom Lane wrote:
I distinctly recall us getting bashed a few years ago because there
wasn't any convenient way to turn SSL compression *on*. Now that SSL
finally does the sane thing by default, you want to turn it off?
The
On Tue, Nov 8, 2011 at 10:54 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Interesting idea. I think in general we insist that you must have a
buffer content lock to inspect the tuple visibility info, in which
case that would be safe. But I'm not sure we do
I think there is a need to provide prefix search to bypass
dictionaries.If you folks think that there is some credibility to such a
need then I can think about implementing it. How about an operator like
:# that does this? The :* will continue to mean the same as
currently.
-Sushant.
On Tue,
On Tue, Nov 8, 2011 at 11:06 AM, k...@rice.edu k...@rice.edu wrote:
I think that JDBC and Npgsql should also support disabling compression.
That's the *real* problem here...
You're quite right that if we allow controlling this on the libpq
side, it is surely desirable to allow controlling this
On Mon, Nov 7, 2011 at 12:20 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
If sepgsql would apply permission checks db_procedure:{install} on the
OAT_POST_CREATE hook based on the funcion-oid within new entry of
system catalog, we can relocate OAT_PREP_CREATE hook more conceptually
right place,
On Sat, Nov 5, 2011 at 10:42 AM, Peter Eisentraut pete...@gmx.net wrote:
We only build the language plpython2u or plpython3u, not both, in any
build, but we always install the extension control files for all
variants. Is there a reason for this, or just an oversight?
Sounds like an oversight.
On 2011-11-08 22:59, Albe Laurenz wrote:
In addition to the oprofile data I collected three times:
- the duration as shown in the server log
- the duration as shown by \timing
- the duration of the psql command as measured by time
[...]
I think this makes a good case for disabling
2011/11/8 Alvaro Herrera alvhe...@commandprompt.com:
Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011:
Isn't that what pagers like 'less' and 'more' do already? May be we
could provide a pager more specific to psql output as a contrib or
extension.
Well, now that
Jeroen Vermeulen j...@xs4all.nl writes:
Another reason why I believe compression is often used with encryption
is to maximize information content per byte of data: harder to guess,
harder to crack. Would that matter?
Yes, it would. There's a reason why the OpenSSL default is what it is.
On 08.11.2011 17:06, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Hmm, it seems to be intentional, but I agree it's very much contrary to
the usual convention that DatumGetXXXP() returns a detoasted and
depacked datum. I think we should change it. I propose the
Hi!
I ran into a problem with PG 9.1 and bug is observed even in master. After
simplifying a query (original was 9Kb long!) it's possible to reproduce it easily:
CREATE TABLE wow (t1 text, t2 text);
CREATE INDEX idx ON wow (t1,t2);
SET enable_seqscan=off;
SET enable_bitmapscan=off;
EXPLAIN
On 11/06/2011 11:55 PM, Mark Kirkwood wrote:
I am guessing (at this point very much guessing) that pg_freespace map
may return its data faster, as pageinspect is gonna have to grovel
through all the pages for itself (whereas pg_freespacemap relies on
using info from the ... free space map
2011-11-08 18:53 keltezéssel, Heikki Linnakangas írta:
On 08.11.2011 17:06, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Hmm, it seems to be intentional, but I agree it's very much contrary to
the usual convention that DatumGetXXXP() returns a detoasted and
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
The fact of the matter is that in most situations where you want SSL,
ie links across insecure WANs, compression is a win. Testing a local
connection, as you seem to have done, is just about 100% irrelevant to
performance in the real world.
I'm
Teodor Sigaev teo...@sigaev.ru writes:
SELECT
t1, t2
FROM (
SELECT t1, t2 FROM wow
UNION ALL
SELECT 'a', 'a' FROM wow
) t
ORDER BY t1, t2;
Hmm, interesting.
It's seems to me that check in create_merge_append_plan() is too restrictive:
if (memcmp(sortColIdx,
configuration data somewhere else, but we really need to be able to tell
the difference between starting PITR, continuing PITR after a
mid-recovery crash, and finished PITR, up and running normally.
A GUC is not a good way to do that.
Does a GUC make sense to you for how to handle
Given the amount of fixes that went into the branch, and importance of them -
when can we expect 9.1.2 to be released officially ?
9.1.1 was stamped on 22nd of September.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 08.11.2011 20:46, Boszormenyi Zoltan wrote:
2011-11-08 18:53 keltezéssel, Heikki Linnakangas írta:
What do people think of backpatching this? I'm inclined to backpatch, on the
grounds
that the macro that detoasts and depacks should always work (ie. after this
patch), even
if the depacking
Hackers,
I'd really like us to release an alpha version based on the finished
CF2. There have been a number of major features added to PostgreSQL
prior to this CF -- including Haas's performance improvements and range
types -- which we really want at least some users to test early.
Would it be
On 03/01/2011 11:50 AM, Peter Eisentraut wrote:
On fre, 2011-02-11 at 16:49 +0100, Jan Urbański wrote:
I believe it's (b). But as we don't have time for that discussion that
late in the release cycle, I think we need to consider it identical to (c).
As I previously mentioned, I think that
On Sun, Nov 6, 2011 at 5:38 AM, Magnus Hagander mag...@hagander.net wrote:
Looks pretty useful.
thanks for the review, attached is a new version of it
One quick stylistic comment - we don't generally use * 1.0 to turn
an int into a double - just use a cast.
ok
Hooking into a ring
This is the time of year when the Wisconsin Courts formalize their
annual plan for where people will be spending the bulk of their time
in the coming year. Two years ago at this time, managers decided
that serializable transactions were a big enough issue to justify
assigning about half of my
I was curious if anyone running into these problems has gotten a chance
to test the 3 fixes committed here. It sounded like Linas even had a
repeatable test case?
For easier reference the commits are:
On Wed, Nov 9, 2011 at 12:56 AM, Josh Berkus j...@agliodbs.com wrote:
I'd really like us to release an alpha version based on the finished
CF2. There have been a number of major features added to PostgreSQL
prior to this CF -- including Haas's performance improvements and range
types --
On 8 November 2011 21:23, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
This is the time of year when the Wisconsin Courts formalize their
annual plan for where people will be spending the bulk of their time
in the coming year. Two years ago at this time, managers decided
that
Hi,
I found the following error message misleading:
test=# create table cows2 (LIKE cows);
ERROR: inherited relation cows is not a table
STATEMENT: create table cows2 (LIKE cows);
I'm not trying to inherit a relation, I'm trying to base a table on
it. As it happens, cows is a foreign table,
On Tue, Nov 8, 2011 at 1:07 PM, Greg Smith g...@2ndquadrant.com wrote:
On 11/06/2011 11:55 PM, Mark Kirkwood wrote:
I am guessing (at this point very much guessing) that pg_freespace map may
return its data faster, as pageinspect is gonna have to grovel through all
the pages for itself
Alexander,
People trying range types are likely to try indexes on them. GiST on range
types implementation in head have some limitations:
... it's an alpha. There will always be one more patch.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
On 11/8/11 1:23 PM, Kevin Grittner wrote:
So the question is, would a
patch which does the first two without the third be accepted by the
community?
AFAIC, yes.
For that matter, Part 3 is useful without parts 1 and 2, if someone
wanted to work on that. I recall some academic work on
On 8 Nov 2011, at 21:23, Kevin Grittner wrote:
This is the time of year when the Wisconsin Courts formalize their
annual plan for where people will be spending the bulk of their time
in the coming year. Two years ago at this time, managers decided
that serializable transactions were a big
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
So the question is, would a
patch which does the first two without the third be accepted by the
community?
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the updating of
Stephen Frost sfr...@snowman.net wrote:
Are you thinking of having a background scheduler which handles
the updating of schedule-driven (instead of trigger-driven) MVs..?
I'm trying not to get to far into discussing design in advance of
reviewing previous work and any papers on the topic.
On Nov 8, 2011, at 2:54 PM, Stephen Frost wrote:
So the question is, would a
patch which does the first two without the third be accepted by the
community?
+1 Definitely.
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the updating of
schedule-driven (instead of trigger-driven) MVs..? Not to try to
feature-creep this on you, but you might consider how a new backend
process which handles
I wrote:
Not immediately sure what to do about this. The quick-and-dirty fix
would be to only apply add_child_rel_equivalences to simple inheritance
child relations, for which the added items must be Vars and must be
different (which is what that code is expecting). Seems like a bit of a
On Nov 8, 2011, at 3:25 PM, Josh Berkus wrote:
I'm about 99% sure the answer to that is 'yes'. Are you thinking of
having a background scheduler which handles the updating of
schedule-driven (instead of trigger-driven) MVs..? Not to try to
feature-creep this on you, but you might consider
On 11/08/2011 05:07 PM, Robert Treat wrote:
It's already easy to get good enough numbers based on user space
tools with very little overhead, so I think it's more important that
the server side tool be accurate rather than fast.
What user space method do you consider good enough here? I
On Nov 8, 2011, at 4:23 PM, Josh Berkus wrote:
Well, there has to be some way to refresh an MV at regular intervals, no?
For periodic update matviews, yes. However, Kevin needs only produce
the command/function call for updating a generic periodic matview. He
doesn't need to provide a
No feature-creeping; the two features described will be hard enough.
Besides, we have pg_agent for that.
Well, there has to be some way to refresh an MV at regular intervals, no?
For periodic update matviews, yes. However, Kevin needs only produce
the command/function call for updating a
Greg Jaskiewicz g...@pointblue.com.pl writes:
Given the amount of fixes that went into the branch, and importance of them -
when can we expect 9.1.2 to be released officially ?
9.1.1 was stamped on 22nd of September.
That's barely more than six weeks ago. Usually, in the absence of any
Sushant Sinha sushant...@gmail.com writes:
I think there is a need to provide prefix search to bypass
dictionaries.If you folks think that there is some credibility to such a
need then I can think about implementing it. How about an operator like
:# that does this? The :* will continue to mean
On 17 October 2011 03:04, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 14, 2011 at 11:12 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 12, 2011 at 10:20 PM, Josh Kupershmidt schmi...@gmail.com
wrote:
On the third hand, Josh's previous batch of changes to clean up
psql's
* Josh Berkus (j...@agliodbs.com) wrote:
Well, there has to be some way to refresh an MV at regular intervals, no?
For periodic update matviews, yes. However, Kevin needs only produce
the command/function call for updating a generic periodic matview. He
doesn't need to provide a
On 11/08/2011 07:34 PM, Tom Lane wrote:
I don't recall that we've fixed anything since September that seemed to
warrant an immediate release.
The backup+pg_clog failure issues fixed last week have been a nasty
problem hitting people for a while. Backup corruption is obviously
serious.
On Tue, Nov 8, 2011 at 8:31 PM, Stephen Frost sfr...@snowman.net wrote:
Perhaps that would be an acceptable initial version, but I'd be pretty
disappointed and I certainly don't think we should stop there.
I agree that a built-in job scheduler would be pretty awesome, but I
think it's a
Greg Smith g...@2ndquadrant.com writes:
I was curious how 9.0 fared last year for comparison, here's that data:
Version Date Days Weeks
9.0.009/20/10
9.0.110/04/10142.0
9.0.212/16/107310.4
9.0.301/31/11466.6
9.0.404/18/117711.0
On Tue, Nov 8, 2011 at 3:56 PM, Josh Berkus j...@agliodbs.com wrote:
I'd really like us to release an alpha version based on the finished
CF2. There have been a number of major features added to PostgreSQL
prior to this CF -- including Haas's performance improvements and range
types -- which
On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas robertmh...@gmail.com wrote:
But I can't help feeling that as we continue to add more features,
we've eventually going to end up with our backs to the wall. Not sure
what to do about that, but...
Seriously, parts of psql are starting to become a
On Tue, Nov 8, 2011 at 8:12 PM, Thom Brown t...@linux.com wrote:
Why is this marked as done on with Wiki's todo list?
I assume you're referring to this item:
--
\dd is missing comments for several types of objects. Comments are
not handled at all for some object types, and are handled by both
Josh Kupershmidt schmi...@gmail.com writes:
We're essentially pretending that we support all server versions with
this code, instead of erroring out on some definite old version and
admitting sorry, can't do it. ...
I think we should draw a line somewhere about just how far back psql
must
On 11/08/2011 04:23 PM, Kevin Grittner wrote:
http://wiki.postgresql.org/wiki/Materialized_Views
That page describes three components: creating MVs, updating MVs, and
having the planner automatically detect when an MV matches some
portion of a regular query and using the MV instead of the
On 11/08/2011 09:31 PM, Robert Haas wrote:
I know various people are working on patches to do various things, but the
only outstanding thing that sticks out in my mind as an outstanding
big feature patch is Alvaro's work on foreign key locks. I'm sure
there must be others... but I'm not sure
On mån, 2011-11-07 at 12:21 -0500, Robert Haas wrote:
As I'm plotting to write code for this, I wonder about how to handle
default privileges. For compatibility and convenience, we would
still
want to have types with public privileges by default. Should we
continue to hardcode this, as
On Nov 9, 2011 3:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith g...@2ndquadrant.com writes:
I was curious how 9.0 fared last year for comparison, here's that data:
Version Date Days Weeks
9.0.009/20/10
9.0.110/04/10142.0
9.0.212/16/107310.4
Peter Eisentraut pete...@gmx.net writes:
Let me put this differently. Should we either continue to hardcode the
default privileges in the acldefault() function, or should we instead
initialize the system catalogs with an entry in pg_default_acl as though
ALTER DEFAULT PRIVILEGES GRANT USAGE
After some thought and experimentation, the best fix seems to be to
eliminate the ambiguity by wrapping subquery outputs in PlaceHolderVars
whenever there is a risk of confusion. The attached crude patch fixes
both test cases. It needs work (more comments and a regression test
case would be
83 matches
Mail list logo
