On Thu, Jul 3, 2014 at 10:56 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Jul 1, 2014 at 4:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
Further review of patch:
1.
/*
* pg_atomic_test_and_set_flag - TAS()
*
* Acquire/read barrier semantics.
*/
STATIC_IF_INLINE_DECLARE bool
On Mon, Jul 7, 2014 at 11:46 PM, Greg Stark st...@mit.edu wrote:
On Mon, Jul 7, 2014 at 3:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I doubt it. The extra code isn't the problem so much, it's the extra
planning cycles spent trying to make proofs that will usually fail.
What you propose
As a follow-up question,
I found some of the varchar column types, in which the histogram_bounds are
not being surrounded in double quotes ( ) even in the default
implementation.
Ex : *c_name* column of *Customer* table
I also found histogram_bounds in which only some strings are surrounded in
Hi all
I was jotting notes about this last sleepless night, and was really glad
to see the suggestion of enabling RLS on a table being a requirement for
OR-style quals suggested in the thread when I woke.
The only sane way to do OR-ing of multiple rules is to require that
tables be switched to
Attached is a WIP patch for the following:
/*
* postgresPlanForeignModify
* Plan an insert/update/delete operation on a foreign table
*
* Note: currently, the plan tree generated for UPDATE/DELETE will always
* include a ForeignScan that retrieves ctids (using SELECT FOR UPDATE)
* and
Ok, I was able to figure out that when strings contained 'spaces',
PostgreSQL appends them with double quotes.
On Tue, Jul 8, 2014 at 12:04 PM, Ashoke s.ash...@gmail.com wrote:
As a follow-up question,
I found some of the varchar column types, in which the histogram_bounds
are not being
Over here -
http://www.postgresql.org/message-id/6351.1404663...@sss.pgh.pa.us Tom
noted that create_unique_path did not check for set returning functions.
Tom Wrote:
I notice that create_unique_path is not paying attention to the question
of whether the subselect's tlist contains SRFs or
On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
On Mon, Jul 7, 2014 at 4:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I poked around to see if we didn't have some code already for that, and
soon found that not only do we have such
I don't know enough about XML/XPATH to know if this is a good idea or not,
Actually currently because of the namespace problem, xpath() returns wrong
result (even worse: invalid xml!). So this patch corrects the behavior of
xpath() to the correct one.
but I did go read the documentation of
From: Amit Kapila amit.kapil...@gmail.com
On Fri, Jul 4, 2014 at 7:29 PM, MauMau maumau...@gmail.com wrote:
[Hypothesis]
Why does the connection processing emit WAL?
Probably, it did page-at-a-time vacuum during access to pg_database and
pg_authid for client authentication.
From: Rajeev rastogi rajeev.rast...@huawei.com
As of now there is no solution for this in PostgreSQL but I had submitted a
patch Standalone synchronous master in
9.4 2014-01 CommitFest, which was rejected because of some issues. This
patch was meant to degrade the synchronous
level of master,
From: Tom Lane t...@sss.pgh.pa.us
problem, the user might not realize he's got one until he starts to wonder
why autovac/autoanalyze aren't working.
In autovacuum.c, autovacuum workers avoid waiting for the standby by doing:
/*
* Force synchronous replication off to allow regular maintenance
From: Tom Lane t...@sss.pgh.pa.us
Andres Freund and...@2ndquadrant.com writes:
On 2014-07-07 09:57:20 -0400, Tom Lane wrote:
Well, see the comment that explains why the logic is like this now:
I think we should 'simply' make sequences assign a toplevel xid - then
we can get rid of that
On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra t...@fuzzy.cz wrote:
I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
once the table is built and there's free space in work_mem. The patch
mentioned above makes implementing this possible / rather simple.
Another idea would be
From: Asif Naeem anaeem...@gmail.com
Other than my pervious comments, patch looks good to me. Thanks.
Thanks for reviewing. I understood that your previous comment was to
suggest copying the desired DLLs directly from Release/Debug folder to bin.
But I'm afraid it cannot be done cleanly...
On 8 Červenec 2014, 14:49, Robert Haas wrote:
On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra t...@fuzzy.cz wrote:
I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
once the table is built and there's free space in work_mem. The patch
mentioned above makes implementing this
On Sat, Jul 5, 2014 at 12:46 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
At 2014-07-02 15:51:08 -0700, p...@heroku.com wrote:
Attached revision factors in everyone's concerns here, I think.
Is anyone planning to review Peter's revised patch?
I have been doing some functional tests, and
2014-07-06 14:19 GMT+09:00 Stephen Frost sfr...@snowman.net:
Kaigai,
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
Can you clarify where this is coming from..? It sounds like you're
referring to an existing implementation and, if so, it'd be good to get
more information on how that works
On Tue, Jul 8, 2014 at 9:35 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 8 Červenec 2014, 14:49, Robert Haas wrote:
On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra t...@fuzzy.cz wrote:
I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
once the table is built and there's free space
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes:
On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I doubt it. The extra code isn't the problem so much, it's the extra
planning cycles spent trying to make proofs that will usually fail.
What you propose will create a
David Rowley dgrowle...@gmail.com writes:
I think we should probably include the logic to test for set returning
functions into query_is_distinct_for.
It strikes me that there's only a problem if the SRF is in a tlist entry
that is not one of the DISTINCT or GROUP BY columns, respectively. It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
is there any hint to tell pgxs to compile with gcc -O0 (CFLAGS) ?
regards
geohas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
On Tue, Jul 08, 2014 at 11:19:31AM -0400, Tom Lane wrote:
Moshe Jacobson mo...@neadwerx.com writes:
Seeing that there is only one output column, and that the results are
grouped by this output column, it seems to me that the optimizer should not
even look at the rest of the tables.
The
geohas li...@hasibether.at writes:
is there any hint to tell pgxs to compile with gcc -O0 (CFLAGS) ?
I tend to use
make PROFILE=-O0
which relies on knowing that PG's make rules append $(PROFILE) to CFLAGS.
Alternatively you could just override CFLAGS:
make CFLAGS=whatever
but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you Tom!
make CFLAGS=-O0 was it.
now gdb doesn't print Value optimized out.
regards
On 08/07/14 17:45, Tom Lane wrote:
geohas li...@hasibether.at writes:
is there any hint to tell pgxs to compile with gcc -O0 (CFLAGS) ?
I tend to use
On 8 Červenec 2014, 16:16, Robert Haas wrote:
On Tue, Jul 8, 2014 at 9:35 AM, Tomas Vondra t...@fuzzy.cz wrote:
Maybe. I'm not against setting NTUP_PER_BUCKET=1, but with large outer
relations it may be way cheaper to use higher NTUP_PER_BUCKET values
instead of increasing the number of
On 07/08/2014 17:53, geohas wrote:
make CFLAGS=-O0 was it.
now gdb doesn't print Value optimized out.
If you're using GCC 4.8 or later, consider using it with -Og for that
kind of builds.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
On Tue, Jul 8, 2014 at 6:58 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
2) Checking process goes through all the existing columns of a
relation even a difference of 1 with some other column(s) has already
been found. As we try to limit the number of hints returned, this
seems
On Tue, Jul 8, 2014 at 12:06 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 8 Červenec 2014, 16:16, Robert Haas wrote:
On Tue, Jul 8, 2014 at 9:35 AM, Tomas Vondra t...@fuzzy.cz wrote:
Maybe. I'm not against setting NTUP_PER_BUCKET=1, but with large outer
relations it may be way cheaper to use
Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com
Here's an update that places the socket in a temporary subdirectory of /tmp.
The first attached patch adds NetBSD mkdtemp() to libpgport. The second,
principal, patch uses mkdtemp() to implement this design in pg_regress.
On Sat, Jul 5, 2014 at 10:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
Please find the patch attached to address the above concern. I have
updated docs, so that users can be aware of such behaviour.
I'm in the camp that says that we need to do
On 07/08/2014 10:07 AM, Robert Haas wrote:
I haven't looked at the code in this area too carefully, but it seems
to me like the flow ought to be:
1. Read all of the config files and determine what the final value
present in each config file is.
2. *Then*, in a second pass, enforce
On Thu, Jun 26, 2014 at 4:26 PM, Andreas Karlsson andr...@proxel.se wrote:
On 06/24/2014 03:20 AM, Jeff Janes wrote:
I've tried your 0001 patch, reflecting this refactoring, on Linux and it
caused 'make check' to hang at 'starting postmaster'.
I found the bug in the code, and I have
On 07/06/2014 01:27 AM, Christoph Berg wrote:
Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb.c-setup_config().
This will ensure that unless user is
On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote:
Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com
Here's an update that places the socket in a temporary subdirectory of /tmp.
The first attached patch adds NetBSD mkdtemp() to libpgport. The second,
Re: Noah Misch 2014-07-08 20140708174125.ga1884...@tornado.leadboat.com
On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote:
Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com
Here's an update that places the socket in a temporary subdirectory of
/tmp.
On 8.7.2014 19:00, Robert Haas wrote:
On Tue, Jul 8, 2014 at 12:06 PM, Tomas Vondra t...@fuzzy.cz wrote:
On 8 Červenec 2014, 16:16, Robert Haas wrote:
Right, I think that's clear. I'm just pointing out that you get
to decide: you can either start with a larger NTUP_PER_BUCKET and
then reduce
Hi,
here's my review for this patch.
Generally, the patch addresses a real need, tables often only turn
out to be desired as unlogged if there are performance problems in
practice, and the other way round changing an unlogged table to logged
is way more involved manually than it could be with
On Tue, Jul 8, 2014 at 6:35 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 8 Červenec 2014, 14:49, Robert Haas wrote:
On Wed, Jul 2, 2014 at 8:13 PM, Tomas Vondra t...@fuzzy.cz wrote:
I propose dynamic increase of the nbuckets (up to NTUP_PER_BUCKET=1)
once the table is built and there's free
On Tue, Jul 8, 2014 at 08:21:48PM +0200, Christoph Berg wrote:
Re: Noah Misch 2014-07-08 20140708174125.ga1884...@tornado.leadboat.com
On Tue, Jul 08, 2014 at 07:02:04PM +0200, Christoph Berg wrote:
Re: Noah Misch 2014-06-08 20140608135713.ga525...@tornado.leadboat.com
Here's an update
Peter Geoghegan wrote:
6) Sometimes no hints are returned... Even in simple cases like this one:
=# create table foo (aa int, bb int);
CREATE TABLE
=# select ab from foo;
ERROR: 42703: column ab does not exist
LINE 1: select ab from foo;
^
LOCATION:
On Tue, Jul 8, 2014 at 1:42 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
That's because those two candidates come from a single RTE and have an
equal distance -- you'd see both suggestions if you joined two tables
with each candidate, assuming that each table being joined didn't
On Tue, Jul 8, 2014 at 1:55 PM, Peter Geoghegan p...@heroku.com wrote:
I was worried about the common case where a
column name is misspelled that would otherwise be ambiguous, which is
why that shows a HINT while the single RTE case doesn't
To be clear - I mean a HINT with two suggestions
On 8.7.2014 21:53, Jeff Janes wrote:
On Tue, Jul 8, 2014 at 6:35 AM, Tomas Vondra t...@fuzzy.cz wrote:
Maybe. I'm not against setting NTUP_PER_BUCKET=1, but with large
outer relations it may be way cheaper to use higher NTUP_PER_BUCKET
values instead of increasing the number of batches
Hi,
Thinking about this a bit more, do we really need to build the hash
table on the first pass? Why not to do this:
(1) batching
- read the tuples, stuff them into a simple list
- don't build the hash table yet
(2) building the hash table
- we have all the tuples in a simple list,
David Rowley dgrowle...@gmail.com writes:
On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a bit skeptical as to whether testing for that case is actually worth
any extra complexity. Do you have a compelling use-case? But anyway,
if we do want to allow it, why does it
Yes. Can you please take a look at Win_lib_bin.patch I shared earlier ?, I
think it is or similar approach will be appropriate. Thanks.
Regards,
Muhammad Asif Naeem
On Tue, Jul 8, 2014 at 5:53 PM, MauMau maumau...@gmail.com wrote:
From: Asif Naeem anaeem...@gmail.com
Other than my pervious
Asif Naeem wrote:
Yes. Can you please take a look at Win_lib_bin.patch I shared earlier ?, I
think it is or similar approach will be appropriate. Thanks.
I think the suggestion by Peter Eisentraut upthread was pretty
reasonable -- the Makefiles are already aware that they are building a
shared
On 9 July 2014 09:27, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
On Tue, Jul 8, 2014 at 4:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a bit skeptical as to whether testing for that case is actually
worth
any extra complexity. Do you have a compelling
David Rowley dgrow...@gmail.com writes:
On 9 July 2014 09:27, Tom Lane t...@sss.pgh.pa.us wrote:
On review it looks like analyzejoins.c would possibly benefit from an
earlier fast-path check as well.
Do you mean for non-subqueries? There already is a check to see if the
relation has no
On 09/07/14 05:13, Josh Berkus wrote:
On 07/06/2014 01:27 AM, Christoph Berg wrote:
Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing code in initdb.c-setup_config().
This
I've encountered a corrupt pg_control file on my 9.4 development
cluster. I've mostly been using the cluster for changeset extraction /
slony testing.
This is a 9.4 (currently commit 6ad903d70a440e + a walsender change
discussed in another thread) but would have had the initdb done with an
Steve Singer st...@ssinger.info writes:
I've encountered a corrupt pg_control file on my 9.4 development
cluster. I've mostly been using the cluster for changeset extraction /
slony testing.
This is a 9.4 (currently commit 6ad903d70a440e + a walsender change
discussed in another
On 07/08/2014 10:14 PM, Tom Lane wrote:
Steve Singer st...@ssinger.info writes:
I've encountered a corrupt pg_control file on my 9.4 development
cluster. I've mostly been using the cluster for changeset extraction /
slony testing.
This is a 9.4 (currently commit 6ad903d70a440e + a walsender
Steve Singer st...@ssinger.info writes:
On 07/08/2014 10:14 PM, Tom Lane wrote:
There's no obvious reason to think that this pg_control file is corrupt
on its own terms, but the pg_controldata version you're using expects
the 942 layout. The fact that the server wasn't complaining about this
On Tue, Jul 8, 2014 at 11:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, ALTER SYSTEM is there now and it needs to work right in its first
release. I will go fix this if nobody else does.
I am planing to provide an initial patch for this issue in a day or so, hope
that is not too late.
With
On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood mark.kirkw...@catalyst.net.nz
wrote:
On 09/07/14 05:13, Josh Berkus wrote:
Another could be that during initdb all the uncommented settings be
written to postgresql.auto.conf file rather than to postgresql.conf.
I think we can do this by changing
Amit Kapila amit.kapil...@gmail.com writes:
On Wed, Jul 9, 2014 at 6:40 AM, Mark Kirkwood mark.kirkw...@catalyst.net.nz
wrote:
Yes, but even well behaved users will see this type of error, because
initdb uncomments certain values (ones that are dead certs for being
changed via ALTER SYSTEM
On Mon, Jun 30, 2014 at 8:33 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2014-06-30 13:01 GMT+02:00 Abhijit Menon-Sen a...@2ndquadrant.com:
At 2014-06-30 12:48:30 +0200, pavel.steh...@gmail.com wrote:
+ para
+ Print a failed SQL commands to standard error output. This is
On Tue, Jul 8, 2014 at 7:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ashutosh Bapat ashutosh.ba...@enterprisedb.com writes:
On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I doubt it. The extra code isn't the problem so much, it's the extra
planning cycles spent trying to
60 matches
Mail list logo
