Re: [HACKERS] [GENERAL] Issues with generate_series using integer boundaries
On Mon, Feb 7, 2011 at 20:38, Thom Brown t...@linux.com wrote: Yes, of course, int8 functions are separate. I attach an updated patch, although I still think there's a better way of doing this. Thanks. Please add the patch to the *current* commitfest because it's a bugfix. https://commitfest.postgresql.org/action/commitfest_view?id=9 I've not tested the patch yet, but if we could drop the following line in the patch, the code could be much cleaner. /* ensure first value in series should exist */ I'm not sure how this should be handled. Should there just be a check for either kind of infinity and return an error if that's the case? I Maybe so. It also works if we had infinity on timestamp overflow, but I've not tested yet. Anyway, we need similar fix for timestamp versions. -- Itagaki Takahiro -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [HACKERS] [GENERAL] Issues with generate_series using integer boundaries
On Wed, Feb 9, 2011 at 10:17, Andrew Dunstan and...@dunslane.net wrote: Isn't this all really a bug fix that should be backpatched, rather than a commitfest item? Sure, but we don't have any bug trackers... -- Itagaki Takahiro -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [HACKERS] [GENERAL] Issues with generate_series using integer boundaries
On Fri, Feb 4, 2011 at 21:32, Thom Brown t...@linux.com wrote:
The issue is that generate_series will not return if the series hits
either the upper or lower boundary during increment, or goes beyond
it. The attached patch fixes this behaviour, but should probably be
done a better way. The first 3 examples above will not return.
There are same bug in int8 and timestamp[tz] versions.
We also need fix for them.
=# SELECT x FROM generate_series(9223372036854775807::int8,
9223372036854775807::int8) AS a(x);
=# SELECT x FROM generate_series('infinity'::timestamp, 'infinity', '1
sec') AS a(x);
=# SELECT x FROM generate_series('infinity'::timestamptz, 'infinity',
'1 sec') AS a(x);
postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
postgres=# SELECT x FROM generate_series(1, 9,3) AS a(x);
They work as expected in 9.1dev.
--
Itagaki Takahiro
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [HACKERS] Commitfest: The Good, The Bad, and the Ugly
On Wed, Sep 29, 2010 at 6:03 AM, David Fetter da...@fetter.org wrote: The Good: - Most patches still in play have a reviewer. As far as I remember, there were discussions about the issue A patch has a reviewer, but in Needs Review state for several weeks in 9.0 development. Do we have any plans for it? According to the commitfest app, one patch has only one reviewer at once. A new reviewer might avoid reviewing a patch that have another reviewer already. -- Itagaki Takahiro -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [RRR] [HACKERS] Commitfest: The Good, The Bad, and the Ugly
On Wed, Sep 29, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote: No, the column is very clearly labelled Reviewers, not Reviewer. And we have certainly had patches with more than one person's name in that field in the past. The issue is rather that we don't have enough people reviewing. We haven't had enough people volunteer to do reviews to even assign ONE person to each patch, let alone two. There are, as of this writing, SEVEN patches that have no reviewer at all. Some of them might be too difficult to review. For example, replication or snapshot management requires special skills to review. I'm worrying about new reviewers hesitate to review a patch that has a previous reviewer, and then, if they think the remaining patches are too difficult for them, they would just leave the commitfest page. -- Itagaki Takahiro -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Installing PostgreSQL on Windows 7 Beta Build 7000 64bit - first results
Harald Armin Massa haraldarminma...@gmail.com wrote: 4.) it seems to be no longer cool to have your data below Program Files / Program Files (x86) The default as of know is \ProgramData\application I think all of those directories are only for executable files and not good to store any data. Is it safe to create database cluster under C:\Documents and Settings\postgres or C:\Users\postgres ? UAC often bytes us when we just try to modify the configuration file. I'm not sure which directory should we create $PGDATA -- My Documents, Application Data, Local Settings or direct child of %USERPROFILE%, but anyway some of them would be better than Program Files. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] when COPY violates Primary Keys
Chris [EMAIL PROTECTED] wrote: Joao Ferreira gmail wrote: in case the COPY of a register causes a primary key (or UNIQUE, or FK) violation does the psql restore command try to continue the operation until it has parsed the whole dump, or does it abort on the first violation ? Copy is all or nothing. It'll abort as soon as a violation happens. the bulkloader on pgfoundry (http://pgfoundry.org/projects/pgbulkload/) can apparently handle this for you... No, pg_bulkload is all or nothing for constraints violations. Please use pgloader (http://pgfoundry.org/projects/pgloader/) for the purpose. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] partitioned table insert triggers
Reece Hart [EMAIL PROTECTED] wrote:
c := 'INSERT INTO ' || ctable || ' VALUES (NEW.*)';
Now that my only idea is gone, the question for y'all is: how?
?(Okay, I actually do have one more idea: construct the insert values
list with quote_literal. I'm hoping there's a better way.)
You need to do so in 8.3:
EXECUTE 'INSERT INTO ' || ctable ||
' VALUES( (' || quote_literal(new) || '::' || ptable || ').*)';
In 8.4, the next release, you will be able to use a better way:
EXECUTE 'INSERT INTO ' || ctable || ' VALUES( ($1).* )' USING new;
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Inequality operators are not deduced.
Tom Lane [EMAIL PROTECTED] wrote: ITAGAKI Takahiro [EMAIL PROTECTED] writes: I found that the planner can deduce equality operators, but cannot deduce inequality ones. Are there any plans to improve handling of them? Not particularly; it doesn't seem like something that comes up often enough to be worth the work. Hmm... Then I'll add redundant conditions to where-clause manually in such cases. However, it occured in an actual application ported from another database to postgres. I'll try to improve the handling and tell you if it will come good. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[GENERAL] Inequality operators are not deduced.
Hello, I found that the planner can decude equality operators, but cannot decude inequality ones. Are there any plans to improve handling of them? I initialized tables as below. CREATE TABLE T (i INTEGER PRIMARY KEY); CREATE TABLE U (i INTEGER PRIMARY KEY); INSERT INTO T SELECT generate_series(1, 1); INSERT INTO U SELECT generate_series(1, 10); ANALYZE; The planner can add an implicit equality operator, so the folloing two plans are exactly the same, regardless of the redundant 'U.i = 100'. EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i = 100; EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i = 100 AND U.i = 100; QUERY PLAN -- Nested Loop (cost=0.00..16.56 rows=1 width=8) - Index Scan using t_pkey on t (cost=0.00..8.27 rows=1 width=4) Index Cond: (i = 100) - Index Scan using u_pkey on u (cost=0.00..8.28 rows=1 width=4) Index Cond: (i = 100) However, it seems to be inapplicable for inequality operators. The plan was improved after I added the deduce-able 'U.i = 100' in theory. EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i 100; QUERY PLAN - Merge Join (cost=0.00..340.38 rows=100 width=8) Merge Cond: (t.i = u.i) - Index Scan using t_pkey on t (cost=0.00..10.00 rows=100 width=4) Index Cond: (i 100) - Index Scan using u_pkey on u (cost=0.00..3048.26 rows=10 width=4) EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i 100 AND U.i 100; QUERY PLAN - Merge Join (cost=0.00..11.32 rows=1 width=8) Merge Cond: (t.i = u.i) - Index Scan using t_pkey on t (cost=0.00..10.00 rows=100 width=4) Index Cond: (i 100) - Index Scan using u_pkey on u (cost=0.00..9.94 rows=96 width=4) Index Cond: (i 100) Just for the record, if forcing nested loop joins, plans were the follows. SET enable_mergejoin = off; SET enable_hashjoin = off; EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i 100; QUERY PLAN - Nested Loop (cost=0.00..739.11 rows=100 width=8) - Index Scan using t_pkey on t (cost=0.00..10.00 rows=100 width=4) Index Cond: (i 100) - Index Scan using u_pkey on u (cost=0.00..7.28 rows=1 width=4) Index Cond: (u.i = t.i) EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i 100 AND U.i 100; QUERY PLAN --- Nested Loop (cost=0.00..337.42 rows=1 width=8) - Index Scan using u_pkey on u (cost=0.00..9.94 rows=96 width=4) Index Cond: (i 100) - Index Scan using t_pkey on t (cost=0.00..3.40 rows=1 width=4) Index Cond: ((t.i 100) AND (t.i = u.i)) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Inequality operators are not deduced.
I wrote: However, it seems to be inapplicable for inequality operators. The plan was improved after I added the deduce-able 'U.i = 100' in theory. Sorry, there was a miss. The correct is 'U.i 100'. EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i 100; QUERY PLAN - Merge Join (cost=0.00..340.38 rows=100 width=8) Merge Cond: (t.i = u.i) - Index Scan using t_pkey on t (cost=0.00..10.00 rows=100 width=4) Index Cond: (i 100) - Index Scan using u_pkey on u (cost=0.00..3048.26 rows=10 width=4) EXPLAIN SELECT * FROM T, U WHERE T.i = U.i AND T.i 100 AND U.i 100; QUERY PLAN - Merge Join (cost=0.00..11.32 rows=1 width=8) Merge Cond: (t.i = u.i) - Index Scan using t_pkey on t (cost=0.00..10.00 rows=100 width=4) Index Cond: (i 100) - Index Scan using u_pkey on u (cost=0.00..9.94 rows=96 width=4) Index Cond: (i 100) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
