Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Further questions about WITHIN GROUP:
Tom I believe that the spec requires that the direct arguments of
Tom an inverse or hypothetical-set aggregate must not contain any
Tom Vars of the current query level.
False.
The spec requires that the
On Fri, Dec 6, 2013 at 7:22 AM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Dec 5, 2013 at 3:50 PM, Josh Berkus j...@agliodbs.com wrote:
There are fairly well researched algorithms for block-based sampling
which estimate for the skew introduced by looking at consecutive rows in
a block. In
On 2013-12-05 17:52:34 -0800, Peter Geoghegan wrote:
Has anyone ever thought about opportunistic ANALYZE piggy-backing on
other full-table scans? That doesn't really help Greg, because his
complaint is mostly that a fresh ANALYZE is too expensive, but it
could be an interesting, albeit risky
Hi,
2013-12-05 15:36 keltezéssel, Antonin Houska írta:
On 12/02/2013 02:23 PM, Boszormenyi Zoltan wrote:
Hi,
I am reviewing your patch.
Thanks. New version attached.
I have reviewed and tested it and marked it as ready for committer.
Best regards,
Zoltán Böszörményi
--
On 2013-12-06 07:22:27 +0100, Pavel Stehule wrote:
I have a report of critical bug (database is temporary unavailability ..
restart is necessary).
PostgreSQL 9.2.4,
24 CPU
140G RAM
SSD disc for all
Database is under high load. There is a few databases with very high number
of similar
I wrote:
Amit Khandekar wrote:
Yes, I agree that rather than looking at the bitmap heap scan to track
the number of pages, we should look somewhere in the underlying index
scan. Yes, we should get a constant number of index pages regardless
of the actual parent table rows.
I agree with
2013/12/6 Andres Freund and...@2ndquadrant.com
On 2013-12-06 07:22:27 +0100, Pavel Stehule wrote:
I have a report of critical bug (database is temporary unavailability ..
restart is necessary).
PostgreSQL 9.2.4,
24 CPU
140G RAM
SSD disc for all
Database is under high load.
Peter Eisentraut pete...@gmx.net writes:
Here is an idea. Add a GUC that basically says something like
use_transforms = on|off. You can then attach that to individual
functions, which is the right granularity, because only the function
knows whether its code expects transforms or not. But
That seems useful. Do we need more information, like whether a client
certificate was presented, or what ciphers were used?
Yes, please show ciphersuite and TLS version too. Andreas, you can use my
recent \conninfo patch as template:
On 12/06/2013 07:25 AM, Peter Eisentraut wrote:
On Tue, 2013-11-26 at 18:10 +0100, Dimitri Fontaine wrote:
The problem is installing a set of extensions where some of them are
already using the new transform feature and some of them are not. We
need a way to cater with that, I think.
Here is
On Fri, Dec 6, 2013 at 2:50 AM, Joe Conway m...@joeconway.com wrote:
On 12/05/2013 07:16 PM, Fabrízio de Royes Mello wrote:
Hi Joe, how are you?
Hi Fabrizio -- great to hear from you! I'm well.
:-)
Well, when Tom sent this email I was reviewing your patch and the
main suggestion is
On Fri, Dec 6, 2013 at 3:39 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 06 December 2013 12:29 Amit Kapila wrote:
Note -
a. Performance is data is taken on my laptop, needs to be tested on
some better m/c b. Attached Patch is just a prototype of chunkwise
concept, code needs to
On 2013-12-05 14:07:39 -0500, Robert Haas wrote:
On Thu, Dec 5, 2013 at 8:29 AM, Andres Freund and...@2ndquadrant.com wrote:
Hm. The API change of on_shmem_exit() is going to cause a fair bit of
pain. There are a fair number of extensions out there using it and all
would need to be littered
From: Peter Eisentraut pete...@gmx.net
Yeah, this is part of a more general problem, which you have
characterized correctly: What is fatal (or error, or warning, ...) to
the client isn't necessarily fatal (or error, or warning, ...) to the
server or DBA.
Thanks. In addition, #5 and #6 in my
On Fri, Dec 06, 2013 at 11:43:55AM +0100, Dr. Andreas Kunert wrote:
That seems useful. Do we need more information, like whether a client
certificate was presented, or what ciphers were used?
Yes, please show ciphersuite and TLS version too. Andreas, you can use my
recent \conninfo patch
From: Tom Lane t...@sss.pgh.pa.us
No. They are FATAL so far as the individual session is concerned.
Possibly some documentation effort is needed here, but I don't think
any change in the code behavior would be an improvement.
You are suggesting that we should add a note like Don't worry about
From: Josh Berkus j...@agliodbs.com
Heck, I'd be happy just to have a class of messages which specifically
means OMG, there's something wrong with the server, that is, a flag
for messages which only occur when PostgreSQL encounters a bug, data
corrpution, or platform error. Right now, I have to
On 2013-12-06 22:35:21 +0900, MauMau wrote:
From: Tom Lane t...@sss.pgh.pa.us
No. They are FATAL so far as the individual session is concerned.
Possibly some documentation effort is needed here, but I don't think
any change in the code behavior would be an improvement.
You are suggesting
Anything else missing?
Functionally it's fine now, but I see few style problems:
- if (port-ssl 0) is wrong, -ssl is pointer. So use just
if (port-ssl).
- Deeper indentation would look nicer with braces.
- There are some duplicated message, could you restructure it so that
each message
From: Alvaro Herrera alvhe...@2ndquadrant.com
There was also the idea that this would be driven off SQLSTATE but this
seems pretty unwieldy to me.
You are referring to this long discussion, don't you?
http://www.postgresql.org/message-id/19791.1335902...@sss.pgh.pa.us
I've read it before,
Hello,
According to this page,
http://www.postgresql.org/docs/current/static/install-procedure.html
client-only installation is possible on UNIX/Linux like this:
gmake -C src/bin install
gmake -C src/include install
gmake -C src/interfaces install
gmake -C doc install
With the
Antonin Houska antonin.hou...@gmail.com wrote:
SELECT *
FROM tab1 a
LEFT JOIN
tab2 b
ON a.i = ANY (
SELECT k
FROM tab3 c
WHERE k = a.i);
This query works with k in any or all tables, but the semantics
certainly vary depending on where k
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I believe that the spec requires that the direct arguments of
Tom an inverse or hypothetical-set aggregate must not contain any
Tom Vars of the current query level.
In any event, going by the
On Mon, Dec 2, 2013 at 12:44:08PM -0500, Bruce Momjian wrote:
On Sat, Nov 30, 2013 at 12:10:19PM -0500, Bruce Momjian wrote:
Drat, you're quite right. I've always included the full certificate
chain in client certs but it's in no way required.
I guess that pretty much means
On 11/11/13, 12:01 PM, Tom Lane wrote:
I do recall Peter saying that the infrastructure knows how to
verify conversion specs in translated strings, so it would have to be
aware of 'z' flags for this to work.
It just checks that the same conversion placeholders appear in the
translation. It
Tested git apply and build again. No warnings.
The regression test also looks good to me now.
I'm done with this review.
(Not sure if I should move it to 'ready for committer' status or the CFM
should do).
// Antonin Houska (Tony)
On 12/06/2013 02:01 PM, Boszormenyi Zoltan wrote:
2013-12-04
On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote:
On 12/05/2013 10:37 PM, Robert Haas wrote:
On Thu, Dec 5, 2013 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be unpleasant to use in some cases, though.
Why would there be more than a few cases in the first place? Who is
MauMau maumau...@gmail.com writes:
That discussion sounds interesting, and I want to take more time to
consider. But what do you think of my original suggestion to easily solve
the current issue? I'd like to remove the current annoying problem first
before spending much time for more
On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
- compute recoveryUntilDelayTime in XLOG_XACT_COMMIT and
XLOG_XACT_COMMIT_COMPACT checks
Why just those? Why not aborts and
On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In general, I think there is no excuse for code in the backend to use
readdir() directly; it should be using ReadDir(), which takes care of this
as well as error reporting.
My understanding is that the fd.c infrastructure can't
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-05 23:01:28 +0200, Heikki Linnakangas wrote:
Right. Not all of the parameters will make sense for a stand-alone backend
though, like the hostname and port number. And I think you need need a new
parameter to pass the path to the
On Fri, Dec 6, 2013 at 1:36 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello
fabriziome...@gmail.com wrote:
On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs si...@2ndquadrant.com
wrote:
- compute recoveryUntilDelayTime in XLOG_XACT_COMMIT
It looks like this is a fairly well understood problem because in the
real world it's also often cheaper to speak to people in a small
geographic area or time interval too. These wikipedia pages sound
interesting and have some external references:
http://en.wikipedia.org/wiki/Cluster_sampling
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In general, I think there is no excuse for code in the backend to use
readdir() directly; it should be using ReadDir(), which takes care of this
as well as error reporting.
My
Last week's status:
Fri Nov 29
Status Summary. Needs Review: 29, Waiting on Author: 33, Ready for
Committer: 13, Committed: 24, Returned with Feedback: 5, Rejected: 5.
Total: 109.
Current status:
Fri Dec 6 10:55
Status Summary. Needs Review: 24, Waiting on Author: 21, Ready for
Committer: 14,
On 2013-12-06 11:02:48 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
My feeling is that we should just treat the executable name and data
directory path as new connection parameters, which'd be ignored in
normal-connection mode, just as some other parameters will be
Andres Freund and...@2ndquadrant.com writes:
On 2013-12-06 11:02:48 -0500, Tom Lane wrote:
I think the special-purpose command line switches you mention can be
passed through PGOPTIONS, rather than inventing a new parameter -- do you
have an objection to that?
I am not sure if they currently
On Thu, Dec 5, 2013 at 4:06 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
That's a very interesting idea. I've been thinking that we needed to
preserve the property that new workers could attach to the shared
memory segment at any time, but that might not be necessary in all
case. We
On 06/12/13 04:47, Peter Eisentraut wrote:
On Thu, 2013-12-05 at 00:51 +0100, Álvaro Hernández Tortosa wrote:
The tradeoff seems quite positive to me. I see no strong
reasons why
not do it... am I missing something?
I don't buy your argument. You say, if we make this change,
Álvaro Hernández Tortosa wrote
Note that you are not required to maintain your configuration data in a
postgresql.conf-formatted file. You can keep it anywhere you like, GUI
around in it, and convert it back to the required format. Most of the
I think it is not a very good idea to
I don't especially like the syntax you invented for listing arguments in
CREATE AGGREGATE, especially not the WITHIN GROUP (*) special case.
If we stick with that we're going to need to touch a lot more places than
you have, notably regprocedure. I also fear that this syntax is not
appropriate
On Sun, Nov 24, 2013 at 10:58 AM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Nov 18, 2013 at 1:54 AM, Sameer Thakur samthaku...@gmail.com wrote:
Please find v10 of patch attached. This patch addresses following
review comments
I've cleaned this up - revision attached - and marked it ready
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Regardless of that, though ... what is the reasoning for
Tom inventing pg_get_aggregate_arguments() rather than just making
Tom pg_get_function_arguments() do the right thing?
pg_get_function_arguments()'s interface assumes that the caller is
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Regardless of that, though ... what is the reasoning for
Tom inventing pg_get_aggregate_arguments() rather than just making
Tom pg_get_function_arguments() do the right thing?
I wrote:
One possibility is to forget all the parens and say that the display
looks like
type1, type2 WITHIN GROUP type3, type4
Please don't object that that doesn't look exactly like the syntax
for calling the function, because it doesn't anyway --- remember you
also need ORDER BY in
Fujii Masao masao.fu...@gmail.com writes:
On Sun, Nov 24, 2013 at 10:58 AM, Peter Geoghegan p...@heroku.com wrote:
I decided that queryid should be of type oid, not bigint. This is
arguably a slight abuse of notation, but since ultimately Oids are
just abstract object identifiers (so say the
Kevin Grittner kgri...@ymail.com wrote:
test=# SELECT *
FROM tab1 a
LEFT JOIN
tab2 b
ON a.i = ANY (
SELECT k
FROM tab3 c
WHERE k = a.i);
i | j
---+---
1 | 4
1 | 5
1 | 6
2 |
3 | 4
3 | 5
3 | 6
(7 rows)
SELECT *
FROM
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Please don't object that that doesn't look exactly like the syntax
for calling the function, because it doesn't anyway --- remember
you also need ORDER BY in the call.
Tom Actually, now that I think of it, why not use this syntax for
Tom
Andrew Gierth wrote
Tom == Tom Lane lt;
tgl@.pa
gt; writes:
Please don't object that that doesn't look exactly like the syntax
for calling the function, because it doesn't anyway --- remember
you also need ORDER BY in the call.
Tom Actually, now that I think of it, why not use
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Actually, now that I think of it, why not use this syntax for
Tom declaration and display purposes:
Tom type1, type2 ORDER BY type3, type4
But unfortunately it looks exactly like the
Tom == Tom Lane t...@sss.pgh.pa.us writes:
pg_get_function_arguments()'s interface assumes that the caller is
providing the enclosing parens. Changing it would have meant
returning a result like 'float8) WITHIN GROUP (float8' which I
reckoned would have too much chance of breaking
On Fri, Dec 6, 2013 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There seems to be no problem even if we use bigint as the type of
unsigned 32-bit integer like queryid. For example, txid_current()
returns the transaction ID, i.e., unsigned 32-bit integer, as bigint.
Could you tell me what
On 12/06/2013 01:30 PM, Andrew Gierth wrote:
Since I don't particularly trust my own judgement on aesthetics, I used
the feedback I got from others when deciding what to do. Frankly I think
this one needs wider input than just you and me arguing over it.
Can someone paste examples of the two
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Another thing to think about here is to wonder why the committee chose
Tom anything as verbose as agg(...) WITHIN GROUP (ORDER BY ...) in the
Tom first place. The words ORDER BY certainly seem pretty unnecessary.
All of the ordered-set
On 11/17/13, 1:56 PM, Martijn van Oosterhout wrote:
Looks interesting, though I wonder if you could use fnmatch(3) here. Or
woud that match more than you expect? For example, it would allow
'foo*bar' to match 'foo.bar' which your code doesn't.
The question is whether you'd want that.
We had
Josh Berkus j...@agliodbs.com writes:
Can someone paste examples of the two syntax alternatives we're talking
about here? I've lost track.
I'll leave it to Andrew to describe/defend exactly what his patch is
doing. The alternative I'm thinking about is that in CREATE AGGREGATE
as well as \da
On 12/6/13, 12:29 PM, Álvaro Hernández Tortosa wrote:
What I've been trying to do is summarize what has already been
discussed here and propose a solution. You say that you can already do
those thisngs, but that's not what I have read here. Greg Smith (cc'ed
as I'm quoting you) was
Josh == Josh Berkus j...@agliodbs.com writes:
Since I don't particularly trust my own judgement on aesthetics, I
used the feedback I got from others when deciding what to
do. Frankly I think this one needs wider input than just you and
me arguing over it.
Josh Can someone paste
Andrew Gierth and...@tao11.riddles.org.uk writes:
The patch as submitted answers those questions as follows:
CREATE AGGREGATE func(integer) WITHIN GROUP (text) ...
You've glossed over a significant amount of complexity, as shown by your
example that prints WITHIN GROUP (*), a syntax that
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom 2. For an ordered set function, n must equal aggnfixedargs. We
Tom treat all n fixed arguments as contributing to the aggregate's
Tom result collation, but ignore the sort arguments.
That doesn't work for getting a sensible collation out of
On 18.11.2013 09:28, Albe Laurenz wrote:
Tom Lane wrote:
Tom, could you show us a rope if there is one?
What is it you actually need to fetch?
IIRC, the idea was that most FDWs would do the equivalent of fetching the
primary-key columns to use in an update. If that's what you need, then
Andrew Gierth and...@tao11.riddles.org.uk writes:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Meh. I don't think you can have that and also have the behavior
Tom that multiple ORDER BY items aren't constrained to have the same
Tom collation; at least not without some rule that amounts
Tomas Vondra t...@fuzzy.cz writes:
I think that we should make the documentation more explicit about this
limitation, because the current wording in fdw-callbacks documentation
seems to suggest it's possible to add such hidden columns. At least
that's how I read it before running into this.
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom Not wanting to consider the sort args when there's more than one
Tom doesn't square with forcing them to be considered when there's
Tom just one. It's the same aggregate after all,
This logic is only applied in the patch to aggregates that
From: Tom Lane t...@sss.pgh.pa.us
There is no enthusiasm for a quick-hack solution here, and most people
don't actually agree with your proposal that these errors should never
get logged. So no, that is not happening. You can hack your local
copy that way if you like of course, but it's not
Hello,
It seems that Everyone welcomed the following functionality, and I also want
it to solve some problem. But this doesn't appear to be undertaken.
Recovery target 'immediate'
http://www.postgresql.org/message-id/51703751.2020...@vmware.com
Is there any technical difficulty? May I
MauMau wrote
From: Tom Lane lt;
tgl@.pa
gt;
There is no enthusiasm for a quick-hack solution here, and most people
don't actually agree with your proposal that these errors should never
get logged. So no, that is not happening. You can hack your local
copy that way if you like of
David Johnston wrote
MauMau wrote
From: Tom Lane lt;
tgl@.pa
gt;
There is no enthusiasm for a quick-hack solution here, and most people
don't actually agree with your proposal that these errors should never
get logged. So no, that is not happening. You can hack your local
copy that
MauMau wrote
From: Tom Lane lt;
tgl@.pa
gt;
There is no enthusiasm for a quick-hack solution here, and most people
don't actually agree with your proposal that these errors should never
get logged. So no, that is not happening. You can hack your local
copy that way if you like of
On Thu, Dec 5, 2013 at 2:19 AM, Peter Geoghegan p...@heroku.com wrote:
I did a relatively short variant 'insert' pgbench-tools benchmark,
with a serial primary index created on the pgbench_history table.
Results:
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/insert/
I saw
On Sat, Dec 7, 2013 at 9:06 AM, MauMau maumau...@gmail.com wrote:
It seems that Everyone welcomed the following functionality, and I also want
it to solve some problem. But this doesn't appear to be undertaken.
Indeed, nobody has really showed up to implement that.
Recovery target
On 06/12/2013 22:59, Peter Eisentraut wrote:
On 12/6/13, 12:29 PM, Álvaro Hernández Tortosa wrote:
What I've been trying to do is summarize what has already been
discussed here and propose a solution. You say that you can already do
those thisngs, but that's not what I have read here.
On 06/12/2013 19:11, David Johnston wrote:
Álvaro Hernández Tortosa wrote
Note that you are not required to maintain your configuration data in a
postgresql.conf-formatted file. You can keep it anywhere you like, GUI
around in it, and convert it back to the required format. Most of the
http://en.wikipedia.org/wiki/Cluster_sampling
http://en.wikipedia.org/wiki/Multistage_sampling
I suspect the hard part will be characterising the nature of the
non-uniformity in the sample generated by taking a whole block. Some
of it may come from how the rows were loaded (e.g. older rows
On Thu, Dec 5, 2013 at 6:30 PM, MauMau maumau...@gmail.com wrote:
From: Amit Kapila amit.kapil...@gmail.com
On Wed, Dec 4, 2013 at 7:57 PM, MauMau maumau...@gmail.com wrote:
Approach-2 has been discussed previously to resolve it and it doesn't seem
to be
a good way to handle it. Please
75 matches
Mail list logo
