On Sat, Nov 13, 2010 at 8:13 PM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-11-13 at 20:07 +0200, Peter Eisentraut wrote:
On lör, 2010-11-13 at 12:20 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-11-13 at 11:12 -0500, Tom Lane wrote:
It looks like
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan dar...@darrenduncan.net wrote:
A key component of a good type system is that users can define data types,
and moreover where possible, system-defined types are defined in the same
ways as users define types. For example, stuff like temporal types
On Fri, Nov 12, 2010 at 4:07 PM, Jeff Davis pg...@j-davis.com wrote:
I think the best we'll do is be able to hack on some of the things that
we actively want and have clear use cases for, such as type interfaces.
We might have to give up on some of the more ambitious ideas that
involve
On Sat, Nov 13, 2010 at 08:07:52PM -0500, Tom Lane wrote:
A.M. age...@themactionfaction.com writes:
The goal of this work is to address all of the shortcomings of previous
POSIX shared memory patches as pointed out mostly by Tom Lane.
It seems like you've failed to understand the main
2010/11/14 Marko Tiikkaja marko.tiikk...@cs.helsinki.fi:
On 2010-11-12 8:25 PM +0200, I wrote:
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
.. and a wild patch appears.
This is almost exactly the patch from 2010-02 without
On 10/29/2010 01:47 AM, Pavel Golub wrote:
Hello, Alvaro.
You wrote:
AH Excerpts from Pavel Golub's message of jue oct 28 07:50:24 -0300 2010:
Forgot link to poll:
http://pgolub.wordpress.com/2010/10/28/poll-alter-type-enumtype-add-what-newlabel/
AH Hah, there are 17 votes as of right
Dave Page dp...@pgadmin.org writes:
On Sat, Nov 13, 2010 at 8:13 PM, Peter Eisentraut pete...@gmx.net wrote:
Well, it looks like $(eval) is pretty broken in 3.80, so either we
require 3.81 or we abandon this line of thought.
3.81 might be a problem for Solaris - unless I pay for a support
Daniel Farina drfar...@acm.org writes:
Here are some weaknesses in the SUM aggregate that run up against the
type system. Maybe they'll help crystallize some discussion:
SUM(int2) = int4
SUM(int4) = int8
SUM(int8) = numeric
Some weaknesses:
SUM, of any precision, assumes that the
Martijn van Oosterhout klep...@svana.org writes:
The only real solution seems to me to be to keep a small SysV shared
memory segment for the locking and allocate the rest of the shared
memory some other way.
Yeah, that's been discussed. It throws all the portability gains out
the window. It
On 11/14/2010 10:44 AM, Tom Lane wrote:
And on the fourth hand, what we're buying here is pretty marginal for
developers and of no interest whatever for users.
I still think it's worth looking into whether the bug can be dodged
by shortening the eval calls. But if not, I think I'd vote for
On Nov 14, 2010, at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I still think it's worth looking into whether the bug can be dodged
by shortening the eval calls. But if not, I think I'd vote for
reverting. Maybe we could revisit this in a couple of years.
+1. The current master branch
Robert Haas robertmh...@gmail.com writes:
On Nov 14, 2010, at 10:44 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I still think it's worth looking into whether the bug can be dodged
by shortening the eval calls. But if not, I think I'd vote for
reverting. Maybe we could revisit this in a couple of
On 24/10/10 00:32, Jan Urbański wrote:
On 21/10/10 20:48, Alvaro Herrera wrote:
... and presumably somebody can fix the real bug that Jean-Baptiste hit,
too.
AFAICS the error comes from PLy_function_handler disconnecting from SPI
after calling into the Python code and then going ahead and
On Nov 14, 2010, at 7:42 AM, Andrew Dunstan wrote:
It's fairly unscientific and inconclusive, and the discussion seems to have
died. I think since Tom and I did most of the work on this our voices should
count a little louder :-) , so I'm going to go with his suggestion of VALUE,
unless
I wrote:
I still think it's worth looking into whether the bug can be dodged
by shortening the eval calls.
In fact, that does seem to work; I'll commit a patch after testing a
bit more.
We still need someone to add the missing build dependencies so that
make -j is trustworthy again.
On 2010-11-14 5:28 PM +0200, Hitoshi Harada wrote:
2010/11/14 Marko Tiikkajamarko.tiikk...@cs.helsinki.fi:
.. and a wild patch appears.
Could you update wiki on this feature if you think we've reached the consensus?
You're probably referring to
On 2010-11-14 8:01 PM +0200, I wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo.
Since the example wasn't entirely clear on this one: in my opinion the
DML should also only be executed once. So:
WITH t AS (INSERT INTO foo VALUES (0) RETURNING *)
On Sun, Oct 24, 2010 at 01:32, Jan Urbański wulc...@wulczer.org wrote:
The error handling in plpython is well-known to be a mess, hence the
confusing error message that OP got. Another annoying thing is that SPI
calls are not done in a subtransaction, which means you can't trap
errors with a
On 14.11.2010 00:29, Robert Haas wrote:
On Sat, Nov 13, 2010 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Hannu Krosingha...@2ndquadrant.com writes:
On Sat, 2010-11-13 at 10:51 -0500, Tom Lane wrote:
If a table has no indexes, we will always decide that any same-page
update operation is a
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any other option means we're going to have trouble predicting
how a query is going to behave.
I think it's clear that's the
On Sun, Nov 14, 2010 at 11:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Martijn van Oosterhout klep...@svana.org writes:
The only real solution seems to me to be to keep a small SysV shared
memory segment for the locking and allocate the rest of the shared
memory some other way.
Yeah, that's
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any other option means we're going to have trouble predicting
how a query is going to
On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
Here are some weaknesses in the SUM aggregate that run up against the
type system. Maybe they'll help crystallize some discussion:
SUM(int2) = int4
SUM(int4) = int8
SUM(int8) = numeric
details from me about.
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD
merge-v203-20101114.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any other option means we're going
On 13.11.2010 17:07, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Come to think of it, I'm not really sure I understand what protects
SetLatch() against memory ordering hazards. Is that actually safe?
Hmm ... that's a good question. It certainly *looks* like it could
I'm behind on my list mail so maybe this has been mentioned already, but
when I just tried pg_stat_bgwriter from a build against today's HEAD I
got this:
pgbench=# select count(*) FROM pg_stat_bgwriter;
ERROR: did not find '}' at end of input node
Can someone confirm if this broke recently,
If we got rid of hint bits, we'd need workarounds for the ensuing
massive performance loss. There is no reason whatsoever to imagine
that we'd come out ahead in the end.
Oh, there's no question that we need something which serves the same
purpose as the existing hit bits. But there's a lot
Daniel Farina wrote:
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan dar...@darrenduncan.net wrote:
You don't have to kludge things by implementing arrays as blobs for example;
you can implement them as relations instead. Geospatial types can just be
tuples. Arrays of structured types can just
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 13.11.2010 17:07, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Come to think of it, I'm not really sure I understand what protects
SetLatch() against memory ordering hazards. Is that actually safe?
Hmm ...
I'd say put it on and mark it with an [E]. We could use some more
[E]asy items for that list.
We don't need to add marginally-useful features just because they're
easy. If it doesn't have a real use-case, the incremental maintenance
cost of more code is a good reason to reject it.
I'll
Thanks, Jan.
I tested the patch and it looks fine.
Oleg
On Sun, 14 Nov 2010, Jan Urbaski wrote:
On 24/10/10 00:32, Jan UrbaЪЪski wrote:
On 21/10/10 20:48, Alvaro Herrera wrote:
... and presumably somebody can fix the real bug that Jean-Baptiste hit,
too.
AFAICS the error comes from
Greg Smith g...@2ndquadrant.com writes:
I'm behind on my list mail so maybe this has been mentioned already, but
when I just tried pg_stat_bgwriter from a build against today's HEAD I
got this:
pgbench=# select count(*) FROM pg_stat_bgwriter;
ERROR: did not find '}' at end of input node
Tom Lane wrote:
Worksforme. You probably need a full recompile and/or initdb
Yeah, sorry about the noise. This went away after some more intensive
rebuilding. I think I still want to add some regression testing of this
view as suggested. If that had been there, I'd have been a lot more
On Sun, Nov 14, 2010 at 2:27 PM, Daniel Farina drfar...@acm.org wrote:
On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org writes:
Here are some weaknesses in the SUM aggregate that run up against the
type system. Maybe they'll help crystallize
On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga yebhavi...@gmail.com wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo. Any
Greg Smith g...@2ndquadrant.com writes:
Tom Lane wrote:
Worksforme. You probably need a full recompile and/or initdb
Yeah, sorry about the noise. This went away after some more intensive
rebuilding. I think I still want to add some regression testing of this
view as suggested. If that
Attached patch adds some logging for each individual fsync call made
during a checkpoint, along with a summary at the end. You need to have
the following to see all of the detail:
log_checkpoints=on
log_min_messages=debug1
And here's a sample:
LOG: checkpoint starting: immediate force wait
On Sun, Nov 14, 2010 at 08:07:22PM +0200, Marko Tiikkaja wrote:
On 2010-11-14 8:01 PM +0200, I wrote:
In my opinion, all of these should have the same effect: DELETE all rows
from foo.
Since the example wasn't entirely clear on this one: in my opinion
the DML should also only be executed
On Sun, Nov 14, 2010 at 8:52 PM, Josh Berkus j...@agliodbs.com wrote:
For example, imagine if the hint bits were moved to a separate per-table
bitmap outside the table instead of being stored with each row, as the
current FSM is.
How many times do we have to keep going around the same block?
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 14, 2010 at 1:51 PM, Yeb Havinga yebhavi...@gmail.com wrote:
What if CTE's ever get input parameters?
Then they'd be functions, which we already have.
If you mean something like
prepare foo(int) as
with x as
On 2010-11-14 21:06, Marko Tiikkaja wrote:
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my opinion, all of these should have the same effect: DELETE all
rows
The attached patch adds a new field to pg_stat_bgwriter, counting the
number of times backends execute their own fsync calls. Normally, when
a backend needs to fsync data, it passes a request to the background
writer, which then absorbs the call into its own queue of work to do.
However,
On tor, 2010-11-11 at 19:35 +0200, Marko Tiikkaja wrote:
I apologize, I had misunderstood what you are suggesting. But now
that I do, it seems to be an even worse idea to go your way. Based on
my research, I'm almost certain that the SQL standard says that the
execution order is
On Sun, Nov 14, 2010 at 1:25 PM, Robert Haas robertmh...@gmail.com wrote:
Like Tom, I'm not sure this is really a type-system problem. This
sounds like a complaint that operations on numeric are much slower
than operations on int4 and int8, even for values that could be
represented by either
On Sun, Nov 14, 2010 at 22:37, Greg Smith g...@2ndquadrant.com wrote:
Attached patch adds some logging for each individual fsync call made during
a checkpoint, along with a summary at the end. You need to have the
following to see all of the detail:
log_checkpoints=on
Greg Stark gsst...@mit.edu writes:
On Sun, Nov 14, 2010 at 8:52 PM, Josh Berkus j...@agliodbs.com wrote:
For example, imagine if the hint bits were moved to a separate per-table
bitmap outside the table instead of being stored with each row, as the
current FSM is.
How many times do we have
Daniel Farina drfar...@acm.org writes:
There are other ways one might be able to attack the performance part
of the problem, but consider the loss of information about the type
from int(2|4|8) to numeric when composing a series of sums: we know
the value produced fits the abstract notion of an
On Sun, Nov 14, 2010 at 5:07 PM, Greg Smith g...@2ndquadrant.com wrote:
The patch also adds some logging to the innards involved here, to help with
understanding problems in this area. I don't think that should be in the
version committed as is. May want to drop the logging level or make it
Robert Haas robertmh...@gmail.com writes:
With those changes, I think this is committable, and will do so,
barring objections.
Obey message style guidelines, please, especially if you're going
to promote any of those to ereports.
regards, tom lane
--
Sent via
On 11/14/2010 05:15 PM, Tom Lane wrote:
Josh is ignoring the proposal that is on the table and seems actually
workable, which is to consult the visibility map during index-only
scans. For mostly-static tables this would save trips to the heap for
very little extra I/O. The hard part is to
On Sun, Nov 14, 2010 at 11:02:08PM +0100, Yeb Havinga wrote:
On 2010-11-14 21:06, Marko Tiikkaja wrote:
On 2010-11-14 8:51 PM +0200, Yeb Havinga wrote:
On 2010-11-14 19:35, Robert Haas wrote:
On Sun, Nov 14, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
In my
That it's not ready for commit this minute does not mean that it
shouldn't be in the CF this month. Delaying the first review of the
patch until the next CF pretty much ensures that we'll miss 9.1 with
it, so please add to the current CF :)
Cheers,
David.
On Sat, Nov 13, 2010 at 02:15:40PM
On Sun, Nov 14, 2010 at 6:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
With those changes, I think this is committable, and will do so,
barring objections.
Obey message style guidelines, please, especially if you're going
to promote any of those to
Final patch in this series for today spreads out the individual
checkpoint fsync calls over time, and was written by myself and Simon
Riggs. Patch is based against a system that's already had the two
patches I sent over earlier today applied, rather than HEAD, as both are
useful for measuring
Tom Lane wrote:
If the cause was what I suggested, most likely the other stats views
were broken too --- were you able to pass the regression tests in that
state?
I was having a lot of problems with the system that included regression
test issues, and yelped about this one earlier than I
Magnus Hagander wrote:
I think that it's reasonable for the sort of people who turn log_checkpoints
on to also get the sync summary line, thus it being logged at LOG level.
In that case, wouldn't it make more sense to add a couple of more
fields to the existing line? Easier to
Robert Haas wrote:
I think this one could be removed:
+ if (n 0)
+ elog(DEBUG1,Absorbing %d fsync requests,n);
Right; that one is just there to let you know the patch is working, and
how much the background writer does for you per pass, mainly for the
purpose of
Robert Haas robertmh...@gmail.com writes:
It might be even better to mention that the reason why we couldn't
forward the fsync request is that the fsync request queue is full.
I'm not sure exactly how to phrase that. I thought about:
fsync request queue is full
But that seems not to answer
Greg Smith g...@2ndquadrant.com writes:
The way you've explained it now, I see why it's not worth adding a
specific regression test for this in the future, and what else I should
have checked when I ran into my problem (that other system stats views
were also working or not).
FWIW, I
Despite some jerk submitting three brand new patches at the last minute
by himself, the November CommitFest is now closed for new submissions
and ready for review! Only 7 of the 40 patches that need review have a
reviewer assigned so far. Reviewers, mark down a patch you want to look
at in
Marti Raudsepp wrote:
PostgreSQL's default settings change when built with Linux kernel
headers 2.6.33 or newer. As discussed on the pgsql-performance list,
this causes a significant performance regression:
http://archives.postgresql.org/pgsql-performance/2010-10/msg00602.php
NB! I am not
On Sun, Nov 14, 2010 at 7:19 PM, Greg Smith g...@2ndquadrant.com wrote:
But if this is generating a lot of log data or adding a lot of
overhead, then you have bigger problems anyway:
+ elog(DEBUG1, Unable to forward fsync request, executing
directly);
The argument against
On Sun, Nov 14, 2010 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It might be even better to mention that the reason why we couldn't
forward the fsync request is that the fsync request queue is full.
I'm not sure exactly how to phrase that. I
On Sun, Nov 14, 2010 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I still think it's worth looking into whether the bug can be dodged
by shortening the eval calls.
In fact, that does seem to work; I'll commit a patch after testing a
bit more.
We still need someone to add the
On Wed, Nov 3, 2010 at 9:45 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Nov 3, 2010 at 2:19 AM, Michael Meskes mes...@postgresql.org wrote:
On Mon, Nov 01, 2010 at 12:17:02PM +0900, Itagaki Takahiro wrote:
There are some == true in the codes, but they might not be safe
On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina drfar...@acm.org wrote:
SUM(int2) = int4
SUM(int4) = int8
SUM(int8) = numeric
Some weaknesses:
SUM, of any precision, assumes that the precision being accumulated
into (which is also the return-precision) is enough to avoid overflow.
This is
On Mon, Nov 15, 2010 at 11:13, Robert Haas robertmh...@gmail.com wrote:
I added an additional cleanup to 'header_mode' in ecpg; I changed the type
from bool to char to hold 'h' or 'c'. Do you think it is reasonable?
I looked at this but found that part a bit too clever for its own good.
So
This is an update to my earlier patch to add getrusage resource
tracking to EXPLAIN ANALYZE.
With this patch you get something like:
QUERY PLAN
On Fri, Oct 29, 2010 at 2:59 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Gist picksplit method implementation in cube contrib module contains a bug
in Guttman's split algorithm implementation. It was mentioned before but it
is still not fixed yet. Current implementation doesn't cause
On Sun, Nov 14, 2010 at 9:16 PM, Greg Stark gsst...@mit.edu wrote:
On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina drfar...@acm.org wrote:
SUM(int2) = int4
SUM(int4) = int8
SUM(int8) = numeric
Some weaknesses:
SUM, of any precision, assumes that the precision being accumulated
into (which
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost sfr...@snowman.net wrote:
* Jan Urbański (wulc...@wulczer.org) wrote:
On 04/11/10 14:09, Robert Haas wrote:
Hmm, I wonder how useful this is given that restriction.
As
On Fri, Nov 12, 2010 at 00:02, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
Postgres supports ARRAY data types well, but there are some
more array functions in the SQL standard. Also, the standard
has MULTISET data type, that is an unordered array.
Here is a WIP patch for multiset
On Fri, 12 Nov 2010 08:27:54 -0800
Eric Davies e...@barrodale.com wrote:
Thank you for the time estimate and the interface discussion. It
sounds like the PostgreSQL SQL/MED code will be very useful when it
is done. Our product provides read-only access to files, so
updates/inserts/deletes
On Mon, Nov 15, 2010 at 12:41, Shigeru HANADA han...@metrosystems.co.jp wrote:
No, SQL/MED would not support indexing foreign tables, at least in
first version. Because it would be difficult to use common row id for
various FDWs.
I think the reason is the SQL standard never mention about
I've spent a few hours pouring over the source code with
coarse-toothed comb, trying to figure out just exactly what might
break if we changed MyDatabaseId after backend startup time, or in
other words, allowed a backend to unbind from the database to which it
was originally bound and rebind to a
Greg Stark gsst...@mit.edu writes:
Fwiw I think he's right that sum(int2) should perhaps be redefined to
return int8. As it stands all it would take is a 64k rows to
potentially overflow. It's not super likely but it is plausible and
the performance penalty to use int8 wouldn't be super big
Hello
2010/11/15 Itagaki Takahiro itagaki.takah...@gmail.com:
On Fri, Nov 12, 2010 at 00:02, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
Postgres supports ARRAY data types well, but there are some
more array functions in the SQL standard. Also, the standard
has MULTISET data type,
Robert Haas robertmh...@gmail.com writes:
Looking through the code, it appears to me that we'd need to do the
following (not necessarily in this order):
Don't forget
9. Unload loadable modules that do not exist according to the new
database's catalogs; eg we don't want postgis trying to run
On 14.11.2010 22:55, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 13.11.2010 17:07, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Come to think of it, I'm not really sure I understand what protects
SetLatch() against memory ordering hazards.
80 matches
Mail list logo
