On 1 April 2014 20:58, Florian Pflug f...@phlo.org wrote:
On Apr1, 2014, at 10:08 , Dean Rasheed dean.a.rash...@gmail.com wrote:
On 31 March 2014 01:58, Florian Pflug f...@phlo.org wrote:
Attached are updated patches that include the EXPLAIN changes mentioned
above and updated docs.
These
On 04/04/2014 02:40 AM, Andres Freund wrote:
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
A somewhat more relevant concern is where are we going to keep the state
data involved in all this. Since this
Hi,
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
But if we give the checkpointer process a free pass, running the regression
tests with an assertion in AllocSetAlloc catches five genuine bugs:
1. _bt_newroot
2. XLogFileInit
3. spgPageIndexMultiDelete
4. PageRepairFragmentation
On 04/04/2014 11:41 AM, Andres Freund wrote:
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
@@ -484,10 +483,11 @@ PageRepairFragmentation(Page page)
((PageHeader) page)-pd_upper = pd_special;
}
else
- {
On 2014-04-04 12:50:25 +0300, Heikki Linnakangas wrote:
On 04/04/2014 11:41 AM, Andres Freund wrote:
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
@@ -484,10 +483,11 @@ PageRepairFragmentation(Page page)
((PageHeader) page)-pd_upper = pd_special;
}
else
- {
I observed an issue that even if invalid syntax is provided for CREATE TABLE,
table is getting created successfully.
Below table creation succeed even though same constraint name
is given multiple times.
None of the below constraints has any meaning of giving
), which seem reasonable. But
then I started testing performance, and I found cases where the
improvement is not nearly what I expected.
The example cited at the start of this thread is indeed orders of
magnitude faster than HEAD:
SELECT SUM(n::int) OVER (ROWS BETWEEN CURRENT ROW AND
On 04.04.2014, at 09:40, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'm not sure how much additional work is required to sort this out,
but to me it looks more realistic to target 9.5 than 9.4, so at this
point I tend to think that the patch ought to be marked as returned
with feedback.
On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote:
Thanks. To avoid socket path length limitations, I lean toward placing the
socket temporary directory under /tmp rather than placing under the CWD:
On 2014-04-04 12:56:55 +0200, Florian Pflug wrote:
On 04.04.2014, at 09:40, Dean Rasheed dean.a.rash...@gmail.com wrote:
I'm not sure how much additional work is required to sort this out,
but to me it looks more realistic to target 9.5 than 9.4, so at this
point I tend to think that
Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.
It ignores the checkpointer, because it's known to violate the rule, and
allocations in ErrorContext, which is used during
Hi All,
I was comparing postgresql performance and was just curious about
performance in case i want to store the updated index tuple version on a
different page.
I was looking into the code of heapam.c, but was not able to find loop
which i should remove so that postgresql use a different buffer
On 04/04/2014 02:53 PM, Rohit Goyal wrote:
Hi All,
I was comparing postgresql performance and was just curious about
performance in case i want to store the updated index tuple version on a
different page.
I was looking into the code of heapam.c, but was not able to find loop
which i should
On Fri, Apr 4, 2014 at 2:03 PM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
On 04/04/2014 02:53 PM, Rohit Goyal wrote:
Hi All,
I was comparing postgresql performance and was just curious about
performance in case i want to store the updated index tuple version on a
different page.
I
Hey all,
First off, please feel free to let me know if this idea is a waste of time :)
I was thinking about COUNT(*) and its slow performance today, and I
thought about whether we could get better performance by taking a page
out of index-only-scans.
Essentially, the idea is that you would
On Wed, Apr 2, 2014 at 10:27 PM, Andres Freund and...@2ndquadrant.com wrote:
The new master won't necessarily have all the neccessary WAL available, no?
No, they won't have it, and things begin to get bad once a base backup
includes a slot that has a non-null value of restart_lsn. I imagine
that
On 2014-04-04 21:42:33 +0900, Michael Paquier wrote:
On Wed, Apr 2, 2014 at 10:27 PM, Andres Freund and...@2ndquadrant.com wrote:
The new master won't necessarily have all the neccessary WAL available, no?
No, they won't have it, and things begin to get bad once a base backup
includes a slot
On Fri, Apr 4, 2014 at 9:44 PM, Andres Freund and...@2ndquadrant.com wrote:
I imagine
that if we want to guarantee the correctness of a replication slot we
would need to fetch from archives the necessary WAL files needed for
it when a node is in recovery, which is not something that this patch
From feedback on IRC, two immediately obvious technical problems:
* Heap pruning can happen at any time, not just during VACUUM and HOT
updates. This is obviously a pretty significant issue and I doubt the
easy solution (don't do heap pruning for tables with an index like
this) would be
Does anybody care about being able to compile ipc_test as a standalone
binary any more?
I ask because, while working on some of the outstanding cleanup issues
around dynamic shared memory, I made sure to test whether it required
further adjustments based on the changes that I'd done, only to
Hi,
On 2014-04-04 09:31:01 -0400, Robert Haas wrote:
Does anybody care about being able to compile ipc_test as a standalone
binary any more?
I don't.
But if we want to keep it, it should be built during a normal build to
make sure it doesn't get broken.
Greetings,
Andres Freund
--
Andres
y...@netbsd.org (YAMAMOTO Takashi) writes:
On Fri, Apr 04, 2014 at 02:36:05AM +, YAMAMOTO Takashi wrote:
openvswitch has some tricks to overcome the socket path length
limitation using symlink. (or procfs where available)
iirc these were introduced for debian builds which use deep CWD.
Heikki Linnakangas hlinnakan...@vmware.com writes:
Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.
It ignores the checkpointer, because it's known to violate the rule,
Hi,
On 2014-03-08 23:40:31 +0200, Emre Hasegeli wrote:
Fourth version of the patch attached. It is rebased to the HEAD (8879fa0).
Operator name formatting patch rebased on top of it. I will put
the selectivity estimation patch to the next commit fest.
This version of the patch does not
On Wed, Jan 22, 2014 at 10:17 AM, Noah Misch n...@leadboat.com wrote:
Yeah, abandoning the state file is looking attractive.
Here's a draft patch getting rid of the state file. This should
address concerns raised by Heikki and Fujii Masao and echoed by Tom
that dynamic shared memory behaves
On 2014-02-17 10:30:16 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 2/15/14, 10:22 AM, Tom Lane wrote:
Yes it does; people who fail to remove their manual externs will get
Windows-only build failures (or at least warnings; it's not very clear
Hi,
On 2014-01-14 20:58:20 +0900, KONDO Mitsumasa wrote:
I will test some join sqls performance and TPC-3 benchmark in this or next
week.
This patch has been marked as Waiting For Author for nearly two months
now. Marked as Returned with Feedback.
Greetings,
Andres Freund
--
Sent via
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-04 09:31:01 -0400, Robert Haas wrote:
Does anybody care about being able to compile ipc_test as a standalone
binary any more?
I don't.
I can't remember the last time I had use for it either. +1 for removal.
But if we want to keep it,
On 04/04/2014 04:56 PM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.
It ignores the checkpointer,
Joshua Yanovski pythones...@gmail.com writes:
Essentially, the idea is that you would store a counter (let's say, as
a special index type) that would initially (on index creation) be set
to the total count of
all rows on fully visible pages (visibility map bit set to 1).
It seems to me this
Rajeev rastogi rajeev.rast...@huawei.com writes:
Should we not throw error for above syntaxes?
No. There's nothing wrong with those statements, and complaining about
them will accomplish nothing except to break applications that used to
work. Admittedly, code that generates such declarations
Hi,
I personally would very much like to get this patch commited. It doesn't
have much risk in destabilizing stuff, rather the contrary.
Peter, what's you opinion about the current state?
On 2014-02-27 21:44:48 -0500, Peter Eisentraut wrote:
diff --git a/doc/src/sgml/regress.sgml
On 04/04/2014 04:01 PM, Andres Freund wrote:
This patch looks like it can be applied much more realistically, but it
looks too late for 9.4. I suggest moving it to the next CF?
If it does not change the default operator class I do not see anything
preventing it from being applied to 9.4, as
On 2014-01-14 22:22:08 -0500, Peter Eisentraut wrote:
+ listitem
+ para
+Only calculate statistics for use by the optimizer (no vacuum),
+like option--analyze-only/option. Run several stages of analyze
+with different configuration settings, to produce
On Fri, Apr 4, 2014 at 10:32 AM, Heikki Linnakangas
heikki.linnakan...@iki.fi wrote:
In checkpoint, move the check for in-progress xacts out of critical section.
GetVirtualXIDsDelayingChkpt calls palloc, which isn't safe in a critical
section. I thought I covered this case with the exemption
On 2014-04-04 16:50:36 +0200, Andreas Karlsson wrote:
On 04/04/2014 04:01 PM, Andres Freund wrote:
This patch looks like it can be applied much more realistically, but it
looks too late for 9.4. I suggest moving it to the next CF?
If it does not change the default operator class I do not see
On 04/04/2014 06:06 PM, Robert Haas wrote:
On Fri, Apr 4, 2014 at 10:32 AM, Heikki Linnakangas
heikki.linnakan...@iki.fi wrote:
In checkpoint, move the check for in-progress xacts out of critical section.
GetVirtualXIDsDelayingChkpt calls palloc, which isn't safe in a critical
section. I
On Thu, Apr 3, 2014 at 11:28 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-04-02 23:50:19 +0200, Andres Freund wrote:
I just tried it on clang. It builds clean with -Wc11-extensions except
warning about _Static_assert(). That's possibly fixable with some
autoconf trickery.
On 03/08/2014 10:40 PM, Emre Hasegeli wrote:
Fourth version of the patch attached. It is rebased to the HEAD (8879fa0).
Operator name formatting patch rebased on top of it. I will put
the selectivity estimation patch to the next commit fest.
This version of the patch does not touch to the
On Thu, Apr 03, 2014 at 11:44:46PM -0400, Tom Lane wrote:
Peter Geoghegan p...@heroku.com writes:
I think that those are objectively very large reductions in a cost
that figures prominently in most workloads. Based solely on those
facts, but also on the fairly low complexity of the patch,
Hi,
Some comments about the patch:
* Coding Style:
* multiline comments have both /* and */ on their own lines.
* I think several places indent by two tabs.
* Spaces around operators
* ...
* Many of the new comments would enjoy a bit TLC by a native speaker.
* The way RTE_ALIAS creeps in
On Fri, Apr 4, 2014 at 12:13 PM, Noah Misch n...@leadboat.com wrote:
On Thu, Apr 03, 2014 at 11:44:46PM -0400, Tom Lane wrote:
Peter Geoghegan p...@heroku.com writes:
I think that those are objectively very large reductions in a cost
that figures prominently in most workloads. Based solely
Hi,
On 2014-01-14 18:10:40 +0900, Kyotaro HORIGUCHI wrote:
This is cont'd from CF3.
http://www.postgresql.org/message-id/20131122.165927.27412386.horiguchi.kyot...@lab.ntt.co.jp
The issue in brief is that UNION is never flattened differently
to UNION ALL so UNION cannot make use of index
t It seems to me this can't possibly work because of race conditions.
In particular, what happens when some query dirties a page and thereby
clears its fully-visible bit? Presumably, any such query would have
to (1) recompute the number of all-visible rows on that page (already
an expensive
On Thu, Apr 3, 2014 at 7:26 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
On 03/07/2014 05:36 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= fabriziome...@gmail.com
writes:
Do you think is difficult to implement ALTER
VACUUM counter updates, on the other hand, initially seem more
problematic, since if we grab the value of the counter, then VACUUM
updates the counter and the visbility bits, and then we check which
visibility bits are set, we might skip pages we really need to check
(since we're using an old
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-14 18:10:40 +0900, Kyotaro HORIGUCHI wrote:
This patch flattens UNION likewise currently did for UNION ALL.
I haven't really followed this topic, so please excuse my ignorance.
This is still marked as needs review in
Joshua Yanovski pythones...@gmail.com writes:
But worse, what happens if a count(*)
is in progress? It might or might not have scanned this page already,
and there's no way to get the right answer in both cases. Counter
updates done by VACUUM would have a similar race-condition problem.
I
Back in 9.2 (commit 880bfc328) we decided that nonexistent schemas listed
in search_path should be silently ignored, reasoning by analogy with Unix
PATH settings where nonexistent directories in the path don't result in
error reports. This remains imperfect though, cf commit 15386281a and
the
Hi,
On 2014-04-04 13:33:59 -0400, Tom Lane wrote:
It strikes me that the real issue here is that the analogy to PATH is
fine for search_path's role as a *search* path, but it's not so good for
determining the creation target schema. I wonder if we should further
redefine things so that the
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-04 13:33:59 -0400, Tom Lane wrote:
It strikes me that the real issue here is that the analogy to PATH is
fine for search_path's role as a *search* path, but it's not so good for
determining the creation target schema. I wonder if we
On 04/04/2014 01:47 PM, Andres Freund wrote:
I wonder if we could extend the search path syntax to specify whether a
schema should be used for creation of objects or not. Sounds somewhat
nasty, but I don't really have a better idea :(. Something like
search_patch=public,!pg_catalog.
No, if
Helllo. I want to implement knn for spgist. I dont have question with knn, but have questions with implementation of interface. i modify pg_am.h (set amcanorderbyop to true in spgist index).Also i modify pg_amop.h(add DATA(insert ( 4015 600 600 15 o 517 4000 1970 )); ) explain SELECT * FROM
On 2014-04-04 13:58:53 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I wonder if we could extend the search path syntax to specify whether a
schema should be used for creation of objects or not. Sounds somewhat
nasty, but I don't really have a better idea :(. Something
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-04 13:58:53 -0400, Tom Lane wrote:
Hm ... doesn't fix the problem for existing dump files, which are going to
say search_path = foo, pg_catalog. However, we could modify it a bit,
so that the marker is put on schemas that can be skipped
On 2014-04-04 14:13:43 -0400, Tom Lane wrote:
How about simply refusing to create anything in pg_catalog unless it's
explicitly schema qualified? Looks a bit nasty to implement but doable?
That's what happens already. The point is to do better. What we want
for pg_dump's case is to get a
Josh Berkus j...@agliodbs.com writes:
No, if we're fixing this, then we should have a separate
creation_target_schema GUC. The fact that the only way to designate
creation target schema was to put it at the start of the search path has
*always* been a problem, since 7.3.
Well, if we were
Andres Freund and...@2ndquadrant.com writes:
I was thinking - but not saying explicitly - of rigging things so that
pg_catalog is ignored when searching for the target schema for object
creation unless explicitly specified. So if there's no other schema in
the search path you'd get the error
On 2014-04-04 14:32:46 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I was thinking - but not saying explicitly - of rigging things so that
pg_catalog is ignored when searching for the target schema for object
creation unless explicitly specified. So if there's no
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-04 14:32:46 -0400, Tom Lane wrote:
Hm. Seems pretty grotty, but it'd at least fix pg_dump's problem,
since pg_dump's lists are always foo, pg_catalog with no third
schema mentioned. I think what we'd actually need is to say
pg_catalog
On 2014-03-25 21:09:13 +0900, MauMau wrote:
! /*
! * Remove old symlink in recovery, in case it points to the wrong place.
! * On Windows, lstat() reports junction points as directories.
! */
if (InRecovery)
{
! if (lstat(linkloc, st) == 0
I wrote:
However, it's not clear to me that this is worth the trouble. The
DISTINCT would act as an optimization fence preventing the subquery from
being flattened any further, so it doesn't seem like there would be any
global benefit just because it now contains a simple appendrel rather
Hi,
I today tried to cleanup the state of the pending patches a bit. I hope
I haven't bloodied too many toes.
Here's a summary of all patches that aren't either committed, returned
or rejected:
Pending patches waiting for committer are:
c01) Custom Scan APIs
This really seems to need Tom's
On Fri, Apr 4, 2014 at 12:15 PM, Robert Haas robertmh...@gmail.com wrote:
Perhaps I shouldn't lay my own guilt trip on other committers --- but
I think it would be a bad precedent to not deal with the existing patch
queue first.
+1
+1
I don't think we have to promise a strict
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Commit d86d51a95 was pretty damn awful in this regard as well, but
let's clean them both up, not make it worse.
Fair enough. I recall being a bit surprised at it also but didn't spend
much time thinking about it. I'll clean it up.
Thanks,
On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I was actually suggesting that the only way to create something in
pg_catalog is to do it with a explicit schema qualified id. I realize
that that's not something backpatchable...
I don't find that
I wrote:
I still think this stuff mostly needs to be thrown away and rewritten
in Path-creation style, but that's a long-term project. In the meantime
this seems like a relatively small increment of complexity, so maybe it's
worth applying. I'm concerned about the method for building a new
On Fri, Apr 4, 2014 at 5:29 PM, Greg Stark st...@mit.edu wrote:
Two questions I have:
1) Would it make more sense to use a floating point instead of an integer? I
saw a need for a function like this when I was looking into doing GPU sorts.
But GPUs expect floating point values.
In the
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
I don't find that to be a good idea at all. pg_dump is probably not the
only code that believes it can select a creation target with search_path,
no matter what that target is.
Sure, but how many of
On 2014-04-04 17:24:00 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
I don't find that to be a good idea at all. pg_dump is probably not the
only code that believes it can select a creation target with search_path,
no
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-04 17:24:00 -0400, Tom Lane wrote:
Maybe not many, but pg_dump itself certainly can try to do that.
(Most of the time, pg_dump won't dump things in pg_catalog, but there
are exceptions, eg --binary-upgrade dump of an extension containing
Yeah, you're right, I believe that every code path in VACUUM that
leads to the visibility map bit being set also leads to all remaining
tuples on the page being frozen. So in a world without heap pruning,
frozen should be a reliable proxy for value of the tuple the last
time it was added to the
Simon, Dmitri, Peter Eisentraut, and I were chatting at PGConfNYC and
we had an idea for something interesting to do with aggregates.
Interestingly Simon and I came at this from two different directions
but realized we needed the same functionality to implement what we
wanted.
The basic idea is
On 2014-01-15 21:13:18 -0500, Peter Eisentraut wrote:
The attached patch will probably fail to apply because of the pg_proc
changes. So if you want to try it out, look into the header for the Git
hash it was based off. I'll produce a properly merged version when this
approach is validated.
Rajeev rastogi rajeev.rast...@huawei.com writes:
[ pgctl_win32service_rel_dbpath_v6.patch ]
Committed with minor corrections, mostly but not all cosmetic.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Greg Stark st...@mit.edu writes:
The basic idea is to separate the all the properties of the aggregate
functions except the final function from the final function into a
separate object. Giving the optimizer the knowledge that multiple
aggregate functions use the share the same basic machinery
MauMau maumau...@gmail.com writes:
[ pg_ctl_eventsrc_v6.patch ]
I looked at this patch a bit. As a non-Windows person I have no intention
of being the committer, since I can't test the Windows-specific changes.
However, I do want to object to the business about having pg_ctl use
postgres -C to
MauMau maumau...@gmail.com writes:
From: Heikki Linnakangas hlinnakan...@vmware.com
Hmm, why do this only on Windows? If postgres -C is safe enough to run
as Administrator on Windows, why not allow running it as root on Unix as
well? Even if there's no particular need to allow it as root on
I wrote:
I will go and commit this, without the #ifdefs and without the --single
exclusion.
On closer inspection I realized that the switch parsing was still far too
risky, because it would treat -C in any word of the process command line
as a reason not to check for root. Quite aside from the
MauMau maumau...@gmail.com writes:
[ remove_tblspc_symlink_v6.patch ]
Committed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark st...@mit.edu writes:
Well in many cases stype will just be internal for many of them. That
doesn't mean they're the same.
Hm, I suppose it might if they have the same sfunc.
This is actually where I started but we concluded that we needed some
declaration that the aggregates
Well in many cases stype will just be internal for many of them. That
doesn't mean they're the same.
Hm, I suppose it might if they have the same sfunc.
This is actually where I started but we concluded that we needed some
declaration that the aggregates were actually related and would interpret
MauMau maumau...@gmail.com writes:
Then, as a happy medium, how about disabling message localization only if
the client encoding differs from the server one? That is, compare the
client_encoding value in the startup packet with the result of
GetPlatformEncoding(). If they don't match,
On Fri, Apr 4, 2014 at 8:48 PM, Robert Haas robertmh...@gmail.com wrote:
I see. Here's an updated patch with a bit of minor refactoring to
clean that up, and some improvements to the documentation.
I was all ready to commit this when I got cold feet. What's bothering
me is that the patch,
84 matches
Mail list logo
