Bruce Momjian wrote:
I have applied a simplified version of your patch, attached, that adds
just a AND line to the query; I was a little concerned that IN
might affect performance, and the macros seemed kind of complicated.
Thanks.
Also, since my patch this morning any pattern will also
Vlad Arkhipov arhi...@dc.baikal.ru wrote:
Is it possible to print which key value is duplicated when 'Duplicate
key value violates unique constraint' occurs? Foreign key violation
error reports such kind of information.
I think it is not difficult from a technical standpoint.
The attached
Could the list admin please unsubscribe Andreas Zeugswetter from the
lists until he can fix his vacation-responder-gone-nuts?
I am very sorry, fixed. I forgot to set nomail before setting the out of office
assistant
which my company requires me to do in this braindead way.
But I assume
Hi,
We've discussed before the idea that NOT NULL constraints should be
explicitly represented in pg_constraint, just like general CHECK
constraints (this would allow them to be named, have sane inheritance
behavior, etc). If we had that, then pg_attribute.attnotnull could
indicate the OR
HI All,
I had gone through advantages of visibilitymap along with discussion on
thick index. I have a question.
when we have information about visibility of the data, does it make sense to
propagate values of expression stored in index through various slots of
execution tree?
It would be helpful
On Fri, Apr 3, 2009 at 1:48 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
While investigating some performance problems recently I've had cause
to think about the way PostgreSQL uses hash joins. So here are a few
thoughts. Some of these have been
Because your vacation responder is even more broken than that. It
sends the mail to the *From* header address instead of the envelope
from. Aside from not handling mailing lists sanely that also makes it
susceptible to mail loops.
--
Greg
On 3 Apr 2009, at 04:40, Zeugswetter Andreas OSB
Here is a test case that crashes even with the patch:
I was too optimistic :(
Attached patch contains:
- changes in R-tree picksplit methods. Now it checks bad ratio and if so then
use simple split: one half of entries to one page, and another part - to
another page.
- protection from buggy
I wrote:
Bruce Momjian br...@momjian.us writes:
+ereport(NOTICE,
+(errmsg(performing checkpoint)));
You've *got* to be kidding.
Sigh. I have to apologize for that over-hasty complaint: I misread
where you intended to put the message. (Seems like
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Rather than deplore that you can't expedite the checkpoint, why don't we
just make it possible?
+1
The first question is what the default behavior should be? We've seen
enough complaints and I've been bitten by that myself
On Fri, Apr 03, 2009 at 08:03:33AM -0400, Robert Haas wrote:
On Fri, Apr 3, 2009 at 1:48 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
While investigating some performance problems recently I've had cause
to think about the way PostgreSQL uses hash
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
In view of the way that canonicalize_path() works, I can't help thinking
this is going in precisely the wrong direction.
In a way, yes. But canonicalize_path() runs only in the backend, and
this is only in the frontend. I think the
While investigating some performance problems recently I've had cause
to think about the way PostgreSQL uses hash joins. So here are a few
thoughts. Some of these have been brought up before.
1. When the hash is not expected to spill to disk, it preserves the
pathkeys of the outer side of
Teodor Sigaev teo...@sigaev.ru writes:
Here is a test case that crashes even with the patch:
I was too optimistic :(
Attached patch contains:
- changes in R-tree picksplit methods. Now it checks bad ratio and if so then
use simple split: one half of entries to one page, and another part
--On Freitag, April 03, 2009 08:30:14 +0300 Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The first looks nicer, IMHO, because the word 'lazy' makes it
self-documenting. In the second form, you have to look at the manual to
figure out what the 2nd argument does.
Regarding
On Fri, Apr 3, 2009 at 11:24 AM, Lawrence, Ramon ramon.lawre...@ubc.ca wrote:
I would be interested in working with you on any of these changes to
hash join if you decide to pursue them. I am especially interested in
looking at the hash aggregation code and potentially improving its
Josh Berkus j...@agliodbs.com writes:
The other existing bugs I think relate to extreme corner cases (e.g.
ENUMs of DOMAINS) and/or may be feature requests rather than bugs (e.g.
Cover Density Ranking) so I think can safely be put off until 8.4.1 or
later.
As far as the
On Thu, 2009-04-02 at 22:08 -0400, Robert Haas wrote:
3. Avoid building the exact same hash table twice in the same query.
This happens more often you'd think. For example, a table may have
two columns creator_id and last_updater_id which both reference person
(id). If you're considering a
1. When the hash is not expected to spill to disk, it preserves the
pathkeys of the outer side of the join. If the optimizer were allowed
to assume that, it could produce significantly more efficient query
plans in some cases.
This is definitely possible, but you will have to dynamically
On Fri, Apr 3, 2009 at 5:41 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would be especially interested in using a shared memory hash table
that *all* backends can use - if the table is mostly read-only, as
dimension tables often are in data warehouse applications. That would
give zero
Euler Taveira de Oliveira eu...@timbira.com writes:
Alvaro Herrera escreveu:
I'm not sure I'm reading this right, but isn't this preventing a
plpytHon function to work if parameters don't have names assigned?
No. See the proc-argnames test before PyDict_SetItemString(). The other test
is
On Fri, 2009-04-03 at 18:03 +0100, Greg Stark wrote:
I wonder if we need a whole class of index algorithms to deal
specifically with read-only tables
I think we can drop the word index from the sentence as well.
Read-only isn't an isolated case. Often you find many read-only tables
alongside
Simon Riggs si...@2ndquadrant.com wrote:
Read-only isn't an isolated case. Often you find many read-only
tables
alongside rapidly changing tables. So even the busiest of databases
can
benefit from read-only optimisations.
Having changes to those tables cause much heavier additional work is
Tom Lane wrote:
Alvaro's example now gives me this on Fedora 10:
ERROR: PL/Python: PL/Python function unaccent failed
DETAIL: type 'exceptions.TypeError': normalize() argument 2 must be
unicode, not str
which is the same as it did in 8.3. I do not know if that's a bug
or expected
I would be especially interested in using a shared memory hash table
that *all* backends can use - if the table is mostly read-only, as
dimension tables often are in data warehouse applications. That
would
give zero startup cost and significantly reduced memory.
I think that's a
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Alvaro, would you see if it still crashes for you on Debian?
If so there's some other issue with python 2.5.4 ...
It works for me now. Thanks to Euler for tracking the Python problem
down and to you for the commit!
Hmph. I
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
It works for me now. Thanks to Euler for tracking the Python problem
down and to you for the commit!
Hmph. I wonder what caused that crash you reported originally? The
backtrace doesn't look like it's explained by the
Hi,
I've noticed a difference in 8.3.7 vs 8.4 (via git branch -r)
behaviour
8.3
testdb= create table foo (bar bigserial primary key with
(fillfactor=75));
NOTICE: CREATE TABLE will create implicit sequence foo_bar_seq for
serial column foo.bar
NOTICE: CREATE TABLE / PRIMARY KEY will
Khee Chin escribió:
After some debugging in reloptions.c, I've realised that the issue is
caused by fillfactor not having a validnsps in transformRelOptions.
Adding an additional condition (validnsps)) at line 595 or 612
appears to fix the issue.
No, the bug is that they are passed as
Alvaro Herrera escribió:
Khee Chin escribió:
After some debugging in reloptions.c, I've realised that the issue is
caused by fillfactor not having a validnsps in transformRelOptions.
Adding an additional condition (validnsps)) at line 595 or 612
appears to fix the issue.
No, the bug
Simon Riggs si...@2ndquadrant.com writes:
No need to wait for idle-in-transaction sessions during index builds.
GetCurrentVirtualXIDs() specifically *includes* backends that have
proc-xmin == InvalidTransactionId (0), but I'm not sure why.
On further consideration, this patch is simply
Alvaro Herrera alvhe...@commandprompt.com writes:
This patch seems to be the right cure. (Some other users of
opt_definition remain; I think it's just CREATE FUNCTION by now).
Surely this will break other things. I find myself wondering why you
invented ReloptElem at all, instead of adding a
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
This patch seems to be the right cure. (Some other users of
opt_definition remain; I think it's just CREATE FUNCTION by now).
Surely this will break other things. I find myself wondering why you
invented ReloptElem at
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Surely this will break other things. I find myself wondering why you
invented ReloptElem at all, instead of adding a field to DefElem.
I had to, precisely because it messes up other uses of DefElem ...
For example, the
On Fri, Apr 3, 2009 at 12:55 PM, Greg Stark st...@enterprisedb.com wrote:
1. When the hash is not expected to spill to disk, it preserves the
pathkeys of the outer side of the join. If the optimizer were allowed
to assume that, it could produce significantly more efficient query
plans in some
Robert Haas robertmh...@gmail.com writes:
I don't see why hash_inner_and_outer can't walk the outer path looking
for suitable hashes to reuse. I think the question is how aggressive
we want to be in performing that search.
Correct, but you've got the details all wrong. The real problem is
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribi�:
Surely this will break other things. I find myself wondering why you
invented ReloptElem at all, instead of adding a field to DefElem.
I had to, precisely because it messes up other uses of DefElem
Alvaro Herrera escribió:
Tom Lane escribió:
Well, you could still have separate productions that did or didn't allow
qualified names there (or perhaps better, have the code in
functioncmds.c reject qualified names). I think the use of two different
node types is going to result in
Alvaro Herrera alvhe...@commandprompt.com writes:
Well, you could still have separate productions that did or didn't allow
qualified names there (or perhaps better, have the code in
functioncmds.c reject qualified names). I think the use of two different
node types is going to result in
Alvaro Herrera alvhe...@commandprompt.com writes:
... but I don't really see that this buys much of anything. I think a
better answer to this kind of problem would be
+ Assert(IsA(def, ReloptElem));
Well, that will help to make wrong-node-type mistakes more obvious (at
least if you're
On Fri, Apr 3, 2009 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't see why hash_inner_and_outer can't walk the outer path looking
for suitable hashes to reuse. I think the question is how aggressive
we want to be in performing that search.
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 3, 2009 at 4:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Correct, but you've got the details all wrong. The real problem is that
the planner might discard a join path hash(A,B) at level 2 because it
loses compared to, say, merge(A,B). But
On Fri, 2009-04-03 at 15:46 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
No need to wait for idle-in-transaction sessions during index builds.
GetCurrentVirtualXIDs() specifically *includes* backends that have
proc-xmin == InvalidTransactionId (0), but I'm not sure why.
On 3 Apr 2009, at 19:44, Lawrence, Ramon wrote:
I would be especially interested in using a shared memory hash table
that *all* backends can use - if the table is mostly read-only, as
dimension tables often are in data warehouse applications. That
would
give zero startup cost and
The present implementation of interval_hash() is very carefully designed
and coded ... to meet the wrong specification :-(. What it should
be doing is producing equal hashcodes for values that interval_eq()
considers equal. The error is exhibited in the recent bug report #4748.
Attached is a
Simon Riggs si...@2ndquadrant.com writes:
However, the basic premise is that idle-in-transaction sessions do not
need to block index builds.
[ thinks for awhile... ] Actually, I believe that your premise is
correct; the problem is with your proof ;-). Considering only the
xmins is
On Fri, Apr 3, 2009 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think there's a whole lot of choice in the matter. We have to
patch this, and put in the next release notes if you have any hash
indexes on interval columns, REINDEX them after updating. Does anyone
see it
So there's a minor issue on Takahiro-san fillfactor-on-toast patch,
which is that it does not hand out the last possible kind value. This
is a bits32 field, so at least theoretically on some platforms it will
be wider than 32 while on others it will be exactly 32. I'm wondering
if this is the
Alvaro Herrera alvhe...@commandprompt.com writes:
So there's a minor issue on Takahiro-san fillfactor-on-toast patch,
which is that it does not hand out the last possible kind value. This
is a bits32 field, so at least theoretically on some platforms it will
be wider than 32 while on others
Andrew Gierth and...@tao11.riddles.org.uk writes:
Happened to notice this while looking for something else; the \ef
command appears to be missing from \? output. Suggested patch below.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Martin Pihlak martin.pih...@gmail.com writes:
Hmm, this is a problem -- \dX *.* now shows all objects, and there is
no way to list only user objects. This is especially a problem if user
objects are scattered in different schemas.
I don't find this to be a pressing problem. If the user has
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
So there's a minor issue on Takahiro-san fillfactor-on-toast patch,
which is that it does not hand out the last possible kind value. This
is a bits32 field, so at least theoretically on some platforms it will
be wider than
Tom Lane wrote:
I wrote:
Bruce Momjian br...@momjian.us writes:
+ ereport(NOTICE,
+ (errmsg(performing checkpoint)));
You've *got* to be kidding.
Sigh. I have to apologize for that over-hasty complaint: I misread
where you intended to put the
Tom Lane wrote:
I wrote:
Bruce Momjian br...@momjian.us writes:
+ ereport(NOTICE,
+ (errmsg(performing checkpoint)));
You've *got* to be kidding.
Sigh. I have to apologize for that over-hasty complaint: I misread
where you intended to put the
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Still, I don't much like this solution. I agree with Heikki:
let's just fix it.
Agreed, fixing it is better than trying to document/report odd behavior.
There was talk about making pg_start_backup do an immediate checkpoint
but there
Peter Eisentraut pete...@gmx.net writes:
I have recently fixed the configure script to recognize Python 3.0. But
note that building and running PL/Python with Python 3.0 does not
actually work. It looks like several symbols have been removed or
changed. It would be good if the Python
56 matches
Mail list logo
