From: Andres Freund and...@2ndquadrant.com
On 2014-07-18 23:38:09 +0900, MauMau wrote:
LOG: autovacuum: found orphan temp table pg_temp_838.some_table in
database some_db
LOG: autovacuum: found orphan temp table pg_temp_902.some_table in
database some_db
So they had server crashes of some
On Tue, Jul 15, 2014 at 2:17 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Hi, the attached is the revised version.
Thanks Horiguchi-San for the updated patch.
Today while looking into updated patch, I was wondering why can't
we eliminate useless keys in query_pathkeys when we
Agreed. Right now, I'm seeing about updating zic.c to match the IANA code
combined with the modifications that postgres did to it. So far, it doesn't
look like many functional changes have been done, but due to the use of
pgindent, there's a LOT of cosmetic changes that add one heck of a lot of
Hi,
On Sat, Jul 19, 2014 at 09:28:25AM -0400, John Cochran wrote:
Agreed. Right now, I'm seeing about updating zic.c to match the IANA code
combined with the modifications that postgres did to it. So far, it doesn't
look like many functional changes have been done, but due to the use of
On 14.7.2014 06:29, Stephen Frost wrote:
Tomas,
* Tomas Vondra (t...@fuzzy.cz) wrote:
On 6.7.2014 17:57, Stephen Frost wrote:
* Tomas Vondra (t...@fuzzy.cz) wrote:
I can't find the thread / test cases in the archives. I've found this
thread in hackers:
Tomas Vondra t...@fuzzy.cz writes:
I've reviewed the two test cases mentioned here, and sadly there's
nothing that can be 'fixed' by this patch. The problem here lies in the
planning stage, which decides to hash the large table - we can't fix
that in the executor.
We've heard a couple reports
On 13.7.2014 21:32, Tomas Vondra wrote:
The current patch only implemnents this for tuples in the main hash
table, not for skew buckets. I plan to do that, but it will require
separate chunks for each skew bucket (so we can remove it without
messing with all of them). The chunks for skew
On 19.7.2014 20:24, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I've reviewed the two test cases mentioned here, and sadly there's
nothing that can be 'fixed' by this patch. The problem here lies in the
planning stage, which decides to hash the large table - we can't fix
that in the
On Sat, Jul 19, 2014 at 11:58 AM, Michael Banck mba...@gmx.net wrote:
SNIP
Maybe if you pgindent the IANA code as well, you can more easily diff
the actual changes between the two, did you try that?
Michael
Unfortunately, pgindent doesn't work well with the IANA code as evident by
some
On 19.7.2014 20:28, Tomas Vondra wrote:
On 19.7.2014 20:24, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I've reviewed the two test cases mentioned here, and sadly there's
nothing that can be 'fixed' by this patch. The problem here lies in the
planning stage, which decides to hash the
On 19.7.2014 23:07, Tomas Vondra wrote:
On 19.7.2014 20:28, Tomas Vondra wrote:
For the first case, a WARNING at the end of estimate_hash_bucketsize
says this:
WARNING: nbuckets=8388608.00 estfract=0.01
WARNING: nbuckets=65536.00 estfract=0.000267
There are 4.3M rows in the
On 20/07/14 06:30, John Cochran wrote:
On Sat, Jul 19, 2014 at 11:58 AM, Michael Banck mba...@gmx.net
mailto:mba...@gmx.net wrote:
SNIP
Maybe if you pgindent the IANA code as well, you can more easily diff
the actual changes between the two, did you try that?
Michael
On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund and...@2ndquadrant.com wrote:
Meh. A understandable syntax wouldn't require the pullups with a special
scan node and such.
Well, in general ExecModifyTable()/ExecUpdate() trusts the tid passed
to match the qual in the query. Unless you're willing
Someone asked me privately why we weren't immediately pursuing SQL
MERGE, as opposed to yet another non-standard variant of UPSERT
(UPSERT is loosely defined here as an insert-or-update DML command
that goes to update based on would-be unique constraint violations,
and does one or the other
On Fri, Jul 18, 2014 at 7:08 PM, MauMau maumau...@gmail.com wrote:
From: Magnus Hagander mag...@hagander.net
On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander mag...@hagander.net
wrote:
Did anyone actually test
15 matches
Mail list logo
