On Thu, Dec 5, 2013 at 6:30 PM, MauMau wrote:
> From: "Amit Kapila"
>>
>> On Wed, Dec 4, 2013 at 7:57 PM, MauMau wrote:
>>>
>>
>> Approach-2 has been discussed previously to resolve it and it doesn't seem
>> to be
>> a good way to handle it. Please refer link:
>> http://www.postgresql.org/messag
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 were
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. Gr
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
On Sat, Dec 7, 2013 at 9:06 AM, MauMau 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 'immediate'
> http://www.p
On Thu, Dec 5, 2013 at 2:19 AM, Peter Geoghegan 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 something toda
MauMau wrote
> From: "Tom Lane" <
> tgl@.pa
> >
>> 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 o
David Johnston wrote
>
> MauMau wrote
>> From: "Tom Lane" <
>> tgl@.pa
>> >
>>> 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 loca
MauMau wrote
> From: "Tom Lane" <
> tgl@.pa
> >
>> 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 o
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 imple
From: "Tom Lane"
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 getting committed.
> "Tom" == Tom Lane 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 _aren't_
hypo
Tomas Vondra 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.
You can add
Andrew Gierth writes:
> "Tom" == Tom Lane 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 to a
> Tom> special case for percenti
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
> "Tom" == Tom Lane 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
>> perc
Andrew Gierth 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 you've not defined
here.
In th
> "Josh" == Josh Berkus 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 examples
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 ex
Josh Berkus 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 output, the argu
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 ha
> "Tom" == Tom Lane 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 functions that
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
On Fri, Dec 6, 2013 at 12:24 PM, Tom Lane 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 the problem
> "Tom" == Tom Lane 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 existing c
Andrew Gierth writes:
> "Tom" == Tom Lane 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 calling sequence for a
> normal aggre
Andrew Gierth wrote
>> "Tom" == Tom Lane <
> tgl@.pa
> > 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 o
> "Tom" == Tom Lane 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> declaratio
Kevin Grittner 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 *
>>
Fujii Masao writes:
> On Sun, Nov 24, 2013 at 10:58 AM, Peter Geoghegan 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 docs), but also because
>> ther
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 B
Andrew Gierth writes:
> "Tom" == Tom Lane 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
> "Tom" == Tom Lane 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
providing t
On Sun, Nov 24, 2013 at 10:58 AM, Peter Geoghegan wrote:
> On Mon, Nov 18, 2013 at 1:54 AM, Sameer Thakur wrote:
>> Please find v10 of patch attached. This patch addresses following
>> review comments
>
> I've cleaned this up - revision attached - and marked it "ready for
> committer".
>
> I dec
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 for
Á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 i
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, tho
On Thu, Dec 5, 2013 at 4:06 PM, Heikki Linnakangas
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 could introduce
Andres Freund 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 will get recog
On 2013-12-06 11:02:48 -0500, Tom Lane wrote:
> Andres Freund 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 ignored in
> single-user
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,
Robert Haas writes:
> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane 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 infrastr
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
http
On Fri, Dec 6, 2013 at 1:36 PM, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello
> wrote:
> > On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs
> wrote:
> >>
> >> > - compute recoveryUntilDelayTime in XLOG_XACT_COMMIT and
> >> > XLOG_XACT_COMMIT_COMPACT checks
> >>
> >> W
Andres Freund 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 'postgres' executable, un
On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane 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 be used in the
On Thu, Dec 5, 2013 at 11:07 PM, Fabrízio de Royes Mello
wrote:
> On Tue, Dec 3, 2013 at 5:33 PM, Simon Riggs wrote:
>>
>> > - compute recoveryUntilDelayTime in XLOG_XACT_COMMIT and
>> > XLOG_XACT_COMMIT_COMPACT checks
>>
>> Why just those? Why not aborts and restore points also?
>>
>
> I think m
"MauMau" 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 excited infrastruc
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 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
> >going to u
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 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
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 me
Andrew Gierth writes:
> "Tom" == Tom Lane 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 docs on the web, Oracle does not f
Antonin Houska 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 happens to be. It wou
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 attach
From: "Alvaro Herrera"
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, and liked the SQLSTATE-ba
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
On 2013-12-06 22:35:21 +0900, MauMau wrote:
> From: "Tom Lane"
> >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 s
From: "Josh Berkus"
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 suss those ou
From: "Tom Lane"
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 the
following
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 \conni
From: "Peter Eisentraut"
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 previous mail a
On 2013-12-05 14:07:39 -0500, Robert Haas wrote:
> On Thu, Dec 5, 2013 at 8:29 AM, Andres Freund 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 by version depe
On Fri, Dec 6, 2013 at 3:39 PM, Haribabu kommi
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 be impro
On Fri, Dec 6, 2013 at 2:50 AM, Joe Conway 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 about use
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.
> H
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:
https://github.com/markokr/postgres/commit/7d1b27ac7464
Peter Eisentraut 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 you can use t
2013/12/6 Andres Freund
> 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
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 ag
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
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-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 risk
On Fri, Dec 6, 2013 at 7:22 AM, Peter Geoghegan wrote:
> On Thu, Dec 5, 2013 at 3:50 PM, Josh Berkus 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 general, a minimum sample
> "Tom" == Tom Lane 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 direct
75 matches
Mail list logo