On Fri, Jul 24, 2015 at 7:11 AM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Thu, Jul 2, 2015 at 2:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
Looks functionally complete
Need a test to show that ALTER TABLE works on views, as discussed on this
thread. And confirmation that
Hello Horiguchi-san,
As for ForeignScan, it is merely an API for FDW and does nothing
substantial so it would have nothing special to do. As for
postgres_fdw, current patch restricts one execution per one
foreign server at once by itself. We would have to provide
another execution
Hello,
At Thu, 23 Jul 2015 09:38:39 +, Kouhei Kaigai kai...@ak.jp.nec.com wrote
in 9a28c8860f777e439aa12e8aea7694f80111b...@bpxm15gp.gisp.nec.co.jp
I expected workloads like single shot scan on a partitioned large
fact table on DWH system. Yep, if workload is expected to rescan
so
Le 23 juil. 2015 19:27, Alvaro Herrera alvhe...@2ndquadrant.com a
écrit :
Laurent Laborde wrote:
Friendly greetings !
What's the status of parallel clusterdb please ?
I'm having fun (and troubles) applying the vacuumdb patch to clusterdb.
This thread also talk about unifying code
On 07/23/2015 09:38 PM, Robert Haas wrote:
On Wed, Jul 22, 2015 at 12:21 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
This is more invasive than I'd like to backpatch, but I think it's the
simplest approach that works, and doesn't disable any of the important
optimizations we have.
Hmm,
Hello,
After our last upgrade, we've noticed a 10-20% size increase of our dump size.
This comes from our backup scripts were pg_dump was called without setting -Z
So it seems, that this fix did modify the default compression to use:
On 05/02/2015 02:10 AM, Jim Nasby wrote:
This looks like a good way to address this until the more significant
work can be done.
I'm not a fan of RBM_ZERO_NO_BM_VALID; how about RBM_ZERO_BM_INVALID?
or BM_NOT_VALID? Or maybe I'm just trying to impose too much English on
the code; I see the
On Jul 24, 2015, at 7:26 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Fri, Jul 24, 2015 at 12:31 AM, Ildus Kurbangaliev
i.kurbangal...@postgrespro.ru wrote:
Hello.
I’ve changed the previous patch. `group` field in LWLock is removed, so the
size of LWLock will not increase.
Instead
Hi, all.
Attatched is the revised version of this patch.
The first patch is not changed from before.
The second is fixed a kind of bug.
Ths third is the new one to allow backslash continuation for
backslash commands.
hoge.sql is the test custom script.
==
At Fri, 24 Jul 2015 07:39:16
On 2015/07/22 19:10, Etsuro Fujita wrote:
While working on the issue Foreign join pushdown vs EvalPlanQual, I
happened to notice odd behaviors of late row locking in FDWs.
I think the reason for that is because we don't check pushed-down quals
inside an EPQ testing even if what was fetched by
2015-07-23 Robert Haas robertmh...@gmail.com:
I think what you should do is go find out whether the second rationale
is valid or not.
Knowing how much impact on performance such “non TID ordered” entries
have, would of course be very useful for future patch authors to know.
Especially useful
2015-07-24 Nicolas Barbier nicolas.barb...@gmail.com:
Especially useful would be to know whether interleaving a small number
of TID ordered streams (as would probably be generated by parallel
scans/processing) would result in an ordering that performs
significantly worse or not. I assume (but
On 2015-07-12 22:45:18 +0200, Andres Freund wrote:
I'm right now not really coming up with a better idea how to fix
this. So I guess I'll apply something close to this tomorrow.
Took a bit longer than that :(
I've pushed a version of your patch. I just opted to remove p_is_update
instead of
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Andrew The other is that in subquery_planner, the optimization of
Andrew converting HAVING clauses to WHERE clauses is suppressed if
Andrew parse-groupingSets isn't empty. (It is empty if there's either
Andrew no group by clause at
On Mon, Jun 29, 2015 at 8:57 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
pgbench setup
scale factor - 300
Data is on magnetic disk and WAL on ssd.
pgbench -M prepared tpc-b
Head : commit 51d0fe5d
Patch -1 : group_xid_clearing_at_trans_end_rel_v1
Client
Hi,
This will fail too.
Note that, when we have only one element in GROUPING SETS,
we add that in group by list and set parse-groupingSets to NULL.
And hence it will have same issue.
However tests added in my patch failing too.
Thanks
--
Jeevan B Chalke
Principal Software Engineer, Product
On 2015-05-28 18:31:56 -0700, Peter Geoghegan wrote:
Subject: [PATCH 3/3] Fix bug in unique index inference
ON CONFLICT unique index inference had a thinko that could affect cases
where the user-supplied inference clause required that an attribute
match a particular (user named) collation
Jeevan == Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Jeevan Hi,
Jeevan This will fail too.
This is in addition to your patch, not instead of it.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2015-07-22 07:12, Michael Paquier wrote:
On Tue, Jul 21, 2015 at 11:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Petr Jelinek p...@2ndquadrant.com writes:
... My main question is if we are
ok with SCHEMA having different behavior with CASCADE vs without
CASCADE. I went originally with no and
On Mon, Feb 2, 2015 at 8:57 PM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
I've, for a while, pondered whether we couldn't find a easier way than
CSN to make snapshots cheaper as GetSnapshotData() very frequently is
one of the top profile entries. Especially on bigger servers, where the
Fujita-san,
On 2015/07/22 19:10, Etsuro Fujita wrote:
While working on the issue Foreign join pushdown vs EvalPlanQual, I
happened to notice odd behaviors of late row locking in FDWs.
I think the reason for that is because we don't check pushed-down quals
inside an EPQ testing even if
After our last upgrade, we've noticed a 10-20% size increase of our dump
size.
This comes from our backup scripts were pg_dump was called without setting -Z
So it seems, that this fix did modify the default compression to use:
On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey pram...@cleverelephant.ca wrote:
Here's an updated patch that clears the cache on changes to foreign
wrappers and servers.
Any chance one of you folks could by my official commitfest reviewer?
Appreciate all the feedback so far!
On Thu, Jul 23, 2015 at 8:30 AM, Egor Rogov e.ro...@postgrespro.ru wrote:
So, the question: is it a documentation bug (as it seems to me), code bug,
or I missed something?
Your analysis looks right to me, but I don't know whether the code or
the documentation should be changed. This claim was
On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut pete...@gmx.net
wrote:
On 7/21/15 10:00 AM, Tom Lane wrote:
I agree; this change may have seemed like a good idea at the time, but
it was not. Failures
On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar dineshkuma...@gmail.com wrote:
On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar dineshkuma...@gmail.com
wrote:
Sorry for my unclear description about the proposal.
WITH
On 7/23/15 5:18 AM, Thakur, Sameer wrote:
Hello,
logged 25 times
Sorry, it is much lower at 7 times. Does not change overall point though
I think it's related to the problem of figuring out how many dead tuples
you expect to find in the overall heap, which you need to do to have any
hope
On 7/22/15 11:11 AM, Jeff Janes wrote:
I guess add an Assert(InRecovery || running_a_vacuum); to
the visibilitymap_set with a comment there, except that I don't know how
to implement running_a_vacuum so that it covers manual vacs as well as
autovac.
static bool RunningVacuum; ? It only needs
On Fri, Jul 24, 2015 at 1:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
It depends on the exact design we use to get that. Certainly we do not want
them if they cause a significant performance regression.
Yeah. I think the performance worries expressed so far are:
- Currently, if you see an
On 07/24/2015 01:21 PM, Jeff Janes wrote:
On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier
michael.paqu...@gmail.com mailto:michael.paqu...@gmail.com wrote:
On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut
pete...@gmx.net mailto:pete...@gmx.net wrote:
On 7/21/15 10:00 AM, Tom
On 23 July 2015 at 19:59, Josh Berkus j...@agliodbs.com wrote:
On 07/23/2015 11:18 AM, Robert Haas wrote:
Cool. I'm not sure exactly what the right solution is either, but it
seems like the current situation could very well lead to degrading
index performance over time, with no way to put
On 06/25/2015 07:40 AM, Michael Paquier wrote:
On Tue, May 26, 2015 at 3:39 PM, Michael Paquier wrote:
Here is v6, a rebased version on HEAD (79f2b5d). There were some
conflicts with the indentation and some other patches related to
pg_rewind and initdb's tests.
Attached is v7, rebased on
On Fri, Jul 24, 2015 at 2:00 PM, Jim Nasby jim.na...@bluetreble.com wrote:
You need to restrict the amount of info, because you've got to
preallocate enough shared memory to store all the data that somebody
might report.
I was thinking your DSM stuff would come into play here. We wouldn't
On 07/24/2015 01:27 PM, Heikki Linnakangas wrote:
On 06/25/2015 07:40 AM, Michael Paquier wrote:
On Tue, May 26, 2015 at 3:39 PM, Michael Paquier wrote:
Here is v6, a rebased version on HEAD (79f2b5d). There were some
conflicts with the indentation and some other patches related to
pg_rewind
On 24 July 2015 at 14:43, Alexander Korotkov a.korot...@postgrespro.ru
wrote:
What is current state of this patch? Does community want CSN based
snapshots?
CSN snapshots could give us
1. More scalable GetSnapshotData() calls
2. Faster GetSnapshotData() calls
3. Smaller snapshots which could
On 7/24/15 1:53 AM, Heikki Linnakangas wrote:
On 05/02/2015 02:10 AM, Jim Nasby wrote:
This looks like a good way to address this until the more significant
work can be done.
I'm not a fan of RBM_ZERO_NO_BM_VALID; how about RBM_ZERO_BM_INVALID?
or BM_NOT_VALID? Or maybe I'm just trying to
On Fri, Jul 24, 2015 at 2:58 AM, Andres Freund and...@anarazel.de wrote:
I've pushed a version of your patch. I just opted to remove p_is_update
instead of allowing both to be set at the same time. To me that seemed
simpler.
I would be hesitant to remove a struct field from a struct that
On July 24, 2015 7:57:43 PM GMT+02:00, Peter Geoghegan p...@heroku.com wrote:
On Fri, Jul 24, 2015 at 2:58 AM, Andres Freund and...@anarazel.de
wrote:
I've pushed a version of your patch. I just opted to remove
p_is_update
instead of allowing both to be set at the same time. To me that
seemed
On 7/23/15 2:43 PM, Robert Haas wrote:
On Wed, Jul 22, 2015 at 11:28 AM, Jim Nasby jim.na...@bluetreble.com wrote:
If we want to expose that level of detail, I think either JSON or arrays
would make more sense, so we're not stuck with a limited amount of info.
Perhaps DDL would be OK with the
On 07/24/2015 11:06 AM, Jim Nasby wrote:
On 7/23/15 5:18 AM, Thakur, Sameer wrote:
Hello,
logged 25 times
Sorry, it is much lower at 7 times. Does not change overall point though
I think it's related to the problem of figuring out how many dead tuples
you expect to find in the overall
Petr Jelinek p...@2ndquadrant.com writes:
The only major difference that I see so far and I'd like you to
incorporate that into your patch is that I renamed the SampleScanCost to
SampleScanGetRelSize because that reflects much better the use of it, it
isn't really used for costing, but for
Petr Jelinek p...@2ndquadrant.com writes:
Ok, attached are couple of cosmetic changes - what I wrote above, plus
comment about why we do float8 + hashing for REPEATABLE (it's not
obvious IMHO) and one additional test query.
OK, thanks.
Do you want to do the contrib changes yourself as well
On 07/24/2015 02:52 AM, Marc Mamin wrote:
Hello,
After our last upgrade, we've noticed a 10-20% size increase of our dump size.
This comes from our backup scripts were pg_dump was called without setting -Z
So it seems, that this fix did modify the default compression to use:
On Thu, Jul 23, 2015 at 3:01 PM, Ildus Kurbangaliev
i.kurbangal...@postgrespro.ru wrote:
Hello.
I’ve changed the previous patch. `group` field in LWLock is removed, so the
size of LWLock will not increase.
Instead of the `group` field I've created new tranches for LWLocks from
On Thu, Jul 23, 2015 at 1:49 PM, Josh Berkus j...@agliodbs.com wrote:
Batch Jobs: large data-manipulation tasks which need to be broken up
into segments, with each segment committing separately. Example:
updating 1 million records in batches of 1000.
Autonomous transactions are not a good fit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2015 12:40 PM, Dean Rasheed wrote:
On 14 July 2015 at 13:59, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway m...@joeconway.com
wrote:
On 06/08/2015 02:08 AM, Dean Rasheed wrote:
Actually I think it
On 2015-07-24 14:21:39 -0400, Robert Haas wrote:
- Mixing synchronous_commit=on and synchronous_commit=off won't work
as well, because if the LSN ordering of commit records matches the
order in which transactions become visible, then an async-commit
transaction can't become visible before a
On Fri, Jul 24, 2015 at 3:08 AM, Andres Freund and...@anarazel.de wrote:
+ else
+ {
+ Node *nattExpr = list_nth(idxExprs, (natt - 1) -
nplain);
+
+ /*
+ * Note that unlike routines like
On 2015-07-25 00:36, Tom Lane wrote:
I wrote:
Petr Jelinek p...@2ndquadrant.com writes:
The only major difference that I see so far and I'd like you to
incorporate that into your patch is that I renamed the SampleScanCost to
SampleScanGetRelSize because that reflects much better the use of it,
On 7/22/15 4:45 PM, Robert Haas wrote:
But it seemed to me that this could be rather confusing. I thought it
would be better to be explicit about whether the protections are
enabled in all cases. That way, (1) if you see the message saying
they are enabled, they are enabled; (2) if you see
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Saturday, July 25, 2015 2:59 AM
To: Kaigai Kouhei(海外 浩平)
Cc: Etsuro Fujita; pgsql-hackers@postgresql.org
Subject: ##freemail## Re: [HACKERS] fdw_scan_tlist for foreign table scans
breaks
EPQ testing,
On Fri, Jul 24, 2015 at 10:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar dineshkuma...@gmail.com
wrote:
On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar
On Fri, Jul 24, 2015 at 4:26 PM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
On Mon, Jun 29, 2015 at 8:57 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
pgbench setup
scale factor - 300
Data is on magnetic disk and WAL on ssd.
pgbench -M prepared tpc-b
On Sat, Jul 25, 2015 at 3:27 AM, Andrew Dunstan and...@dunslane.net wrote:
On 07/24/2015 01:27 PM, Heikki Linnakangas wrote:
On 06/25/2015 07:40 AM, Michael Paquier wrote:
On Tue, May 26, 2015 at 3:39 PM, Michael Paquier wrote:
Here is v6, a rebased version on HEAD (79f2b5d). There were
On Wed, Aug 27, 2014 at 10:42 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/27/2014 09:40 AM, Heikki Linnakangas wrote:
On 08/27/2014 08:23 AM, Jeff Davis wrote:
On Tue, 2014-08-26 at 13:45 +0300, Heikki Linnakangas wrote:
Yeah. This patch in the current state is likely much
Petr Jelinek p...@2ndquadrant.com writes:
I was wondering if we should perhaps cache the output of GetTsmRoutine
as we call it up to 4 times in the planner now but it's relatively cheap
call (basically just makeNode) so it's probably not worth it.
Yeah, I was wondering about that too. The
Andrew Dunstan and...@dunslane.net writes:
Hmm. Yeah. It looks like commit a7ad5cf0cfcfab8418000d652fa4f0c6ad6c8911
changed from using the default compression for libz to using the
compression set in pg_dump options, which defaults to 0. This actually
seems like the right thing to do, but
Something like that would be helpful. I just had to stop one after an
hour and have no idea how much longer it would have taken.
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RR
On 07/24/2015 05:22 PM, Marc Mamin wrote:
After our last upgrade, we've noticed a 10-20% size increase of our dump size.
This comes from our backup scripts were pg_dump was called without setting -Z
So it seems, that this fix did modify the default compression to use:
On Fri, Jul 24, 2015 at 9:14 PM, Peter Eisentraut pete...@gmx.net wrote:
On 7/22/15 4:45 PM, Robert Haas wrote:
But it seemed to me that this could be rather confusing. I thought it
would be better to be explicit about whether the protections are
enabled in all cases. That way, (1) if you
60 matches
Mail list logo