Hi Szymon
I found a small bug - it doesn't escape "|" well
postgres=# select * from mytab ;
a | numeric_b | c
--+---+
Ahoj |10 | 2014-10-17
Hello|20 | 2014-10-18
Hi |30 | 2014-10-19
aaa| | | 2014-10-17
On 16/10/14 13:29, Pavel Stehule wrote:
Hi
2014-10-14 22:57 GMT+02:00 Petr Jelinek
Great, looks good to me, marking as ready for committer.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mail
Robert Haas wrote
>>> That's an argument in favour of only applying a read-filtering policy
>>> where a RETURNING clause is present, but that introduces the "surprise!
>>> the effects of your DELETE changed based on an unrelated clause!" issue.
>>
>> No- if we were going to do this, I wouldn't want
On 17 October 2014 07:57, Craig Ringer wrote:
> On 10/17/2014 02:49 AM, Robert Haas wrote:
> > I think you could probably make the DELETE policy control what can get
> > deleted, but then have the SELECT policy further filter what gets
> > returned.
>
> That seems like the worst of both worlds to
2014-10-16 Stephen Frost :
> Alright, coming back to this, I have to ask- how are matviews different
> from views from the SQL standard's perspective?
Matviews that are always up to date when you access them are
semantically exactly the same as normal views. Matviews that can get
out of date, how
> >>> In synchronous mode, pg_receivexlog should have similar logic as
> walreceiver does.
> >>
> >> OK. I understand that removing --fsync-interval has no problem.
> >
> > +1 for adding something like --synchronous option. To me,
> > it sounds walreceiver-compatible mode rather than synchronous.
>
Nicolas Barbier wrote
> 2014-10-16 Stephen Frost <
> sfrost@
> >:
>
>> Alright, coming back to this, I have to ask- how are matviews different
>> from views from the SQL standard's perspective?
>
> Matviews that are always up to date when you access them are
> semantically exactly the same as n
(2014/10/16 17:17), Simon Riggs wrote:
On 16 October 2014 06:49, Etsuro Fujita wrote:
How about this?
automatic analyze of table \"%s.%s.%s\" as inheritance tree
Thank you for the comment.
Would it be useful to keep track of how many tables just got analyzed?
i.e. analyze of foo (incl
Hi,
Regarding Loading Custom Format Dump:
===
When we supply plain sql file to pg_restore, we get following error:
$ ./install/bin/pg_restore a.sql
pg_restore: [archiver] input file does not appear to be a valid archive
So I would expect similar kind of message when we provide non-plain sql
file
The attached patches add an ssl_protocols configuration option which
control which versions of SSL or TLS the server will use. The syntax is
similar to Apache's SSLProtocols directive, except that the list is
colon-separated instead of whitespace-separated, although that is easy
to change if it pr
On 17 October 2014 09:55, wrote:
>>A new parameter to send feedback should be called --feedback
>>A second parameter to decide whether to fsync should be called --fsync
>
> I think keep using "--reply-fsync" and "--fsync-interval" is better than make
> new options.
> Thought?
We already have
2014-10-17 9:14 GMT+02:00 Petr Jelinek :
> On 16/10/14 13:29, Pavel Stehule wrote:
>
>> Hi
>>
>> 2014-10-14 22:57 GMT+02:00 Petr Jelinek >
>> Short review of the patch. Note that this has nothing to do with
>> actual assertions, at the moment it's just enhancement of RAISE
>> statement
On Fri, Oct 17, 2014 at 3:49 AM, Robert Haas wrote:
>>> That's an argument in favour of only applying a read-filtering policy
>>> where a RETURNING clause is present, but that introduces the "surprise!
>>> the effects of your DELETE changed based on an unrelated clause!" issue.
>>
>> No- if we wer
On Fri, Oct 17, 2014 at 7:58 PM, Dag-Erling Smørgrav wrote:
> The default is "ALL:-SSLv2" in 9.0-9.3 and "ALL:-SSL" in 9.4 and up.
> This corresponds to the current hardcoded values, so the default
> behavior is unchanged, but the admin now has the option to select a
> different settings, e.g. if
On Tue, Oct 14, 2014 at 11:34 AM, Amit Kapila
wrote:
>
>
> I am not sure why we are seeing difference even though running
> on same m/c with same configuration.
I have tried many times, but I could not get the numbers you have
posted above with HEAD, however now trying with the latest version
[1]
* Fujii Masao (masao.fu...@gmail.com) wrote:
> Another minor problem that I found is that pg_dump always fails when
> there is a row-level policy for update. I think that the attached patch
> should be applied.
Urgh. That was tested before but we switched the characters used and
evidently missed
* Thom Brown (t...@linux.com) wrote:
> On 17 October 2014 07:57, Craig Ringer wrote:
> > On 10/17/2014 02:49 AM, Robert Haas wrote:
> > > I think you could probably make the DELETE policy control what can get
> > > deleted, but then have the SELECT policy further filter what gets
> > > returned.
>
On Fri, Oct 17, 2014 at 1:31 AM, Simon Riggs wrote:
>
> On 16 October 2014 15:09, Amit Kapila wrote:
>
> > I think doing anything on the server side can have higher complexity
like:
> > a. Does this function return immediately after sending request to
> > autovacuum, if yes then the behaviour of
* David G Johnston (david.g.johns...@gmail.com) wrote:
> How about returning a placeholder row but with all the values replaced with
> NULL?
I don't think that would be a good approach.. A user actually looking
at those rows would be highly confused.
> In the absence of returning does the delete
On Thu, Oct 9, 2014 at 3:26 PM, Michael Paquier
wrote:
>
>
> On Wed, Oct 8, 2014 at 10:00 PM, Michael Paquier
> wrote:
>>
>> The additional process at promotion sounds like a good idea, I'll try to
>> get a patch done tomorrow. This would result as well in removing the
>> XLogArchiveForceDone stu
On Fri, Oct 17, 2014 at 7:46 AM, Stephen Frost wrote:
> Thoughts on 'WITH RETURNING' / 'WITHOUT RETURNING' and what the default
> should be?
That sounds like a horrendous pile of nasty complication for no good purpose.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
Hi everyone,
Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
designed for compute intensive OLAP workload. We have gotten it to a
reasonable state and would like to open it up to the pg hackers
community for testing and suggestions.
Vitesse DB offers
-- JIT Compilation for com
On 2014-10-17 14:57:03 +0800, Craig Ringer wrote:
> On 10/17/2014 02:49 AM, Robert Haas wrote:
> > I think you could probably make the DELETE policy control what can get
> > deleted, but then have the SELECT policy further filter what gets
> > returned.
>
> That seems like the worst of both worlds
Michael Paquier writes:
> Please note that new features can only be added to the version
> currently in development, aka 9.5.
I understand this policy. However, this new feature a) has absolutely
no impact unless the admin makes a conscious decision to use it and b)
will make life much easier fo
Hi,
On 2014-10-17 05:32:13 -0700, CK Tan wrote:
> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
> designed for compute intensive OLAP workload. We have gotten it to a
> reasonable state and would like to open it up to the pg hackers
> community for testing and suggestions.
>
On 17 October 2014 12:52, Amit Kapila wrote:
> It is quite possible, but still I think to accomplish such a function,
> we need to have some mechanism where it can inform auto vacuum
> and then some changes in auto vacuum to receive/read that information
> and reply back. I don't think any such
Amit Kapila wrote:
> On Fri, Oct 17, 2014 at 1:31 AM, Simon Riggs wrote:
> >
> > On 16 October 2014 15:09, Amit Kapila wrote:
> > c) seems like the only issue that needs any thought. I don't think its
> > going to be that hard.
> >
> > I don't see any problems with the other points. You can make
On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masao wrote:
> On Thu, Oct 9, 2014 at 3:26 PM, Michael Paquier
> wrote:
>>
>>
>> On Wed, Oct 8, 2014 at 10:00 PM, Michael Paquier
>> wrote:
>>>
>>> The additional process at promotion sounds like a good idea, I'll try to
>>> get a patch done tomorrow. This
On Fri, Oct 17, 2014 at 7:32 AM, CK Tan wrote:
> Hi everyone,
>
> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
> designed for compute intensive OLAP workload. We have gotten it to a
> reasonable state and would like to open it up to the pg hackers
> community for testing and
On Fri, Oct 17, 2014 at 9:23 PM, Fujii Masao wrote:
> In this case, the patch seems to make the restartpoint recycle even WAL
> files
> which have .ready files and will have to be archived later. Thought?
>
The real problem currently is that it is possible to have a segment file
not marked as .do
On Fri, Oct 17, 2014 at 8:14 AM, Merlin Moncure wrote:
> On Fri, Oct 17, 2014 at 7:32 AM, CK Tan wrote:
>> Hi everyone,
>>
>> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
>> designed for compute intensive OLAP workload. We have gotten it to a
>> reasonable state and would l
On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
>
>
> On Wednesday, October 15, 2014, Marti Raudsepp wrote:
>>
>> Hi
>>
>> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma wrote:
>> > Please find attached a patch which implements support for UPDATE table1
>> > SET(*)=...
>>
>> I presume you hav
On Fri, Oct 17, 2014 at 7:45 PM, Merlin Moncure wrote:
> On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
> >
> >
> > On Wednesday, October 15, 2014, Marti Raudsepp wrote:
> >>
> >> Hi
> >>
> >> On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma
> wrote:
> >> > Please find attached a patch which
On 10/17/14 4:15 PM, Merlin Moncure wrote:
Any particular reason why you couldn't have just done:
UPDATE table1 SET * = a,b,c, ...
That just looks wrong to me. I'd prefer (*) = .. over that any day.
UPDATE table1 t SET t = (SELECT (a,b,c)::t FROM...);
seems cleaner than the proposed synt
On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja wrote:
> On 10/17/14 4:15 PM, Merlin Moncure wrote:
>>
>> Any particular reason why you couldn't have just done:
>>
>> UPDATE table1 SET * = a,b,c, ...
>
>
> That just looks wrong to me. I'd prefer (*) = .. over that any day.
>
>> UPDATE table1 t
On 10/17/14 5:03 PM, Merlin Moncure wrote:
Hm, I didn't understand your objection:
So e.g.:
UPDATE foo f SET f = ..;
would resolve to the table, despite there being a column called "f"?
That would break backwards compatibility.
That's not correct: it should work exactly as 'select' does;
On 17 October 2014 14:05, Alvaro Herrera wrote:
> Of course, this is a task that requires much more thinking, design, and
> discussion than just adding multi-process capability to vacuumdb ...
Yes, please proceed with this patch as originally envisaged. No more
comments from me.
--
Simon Rigg
Merlin Moncure writes:
> On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja wrote:
>> I don't know about Tom, but I didn't like that:
>> http://www.postgresql.org/message-id/5364c982.7060...@joh.to
> Hm, I didn't understand your objection:
>
> So e.g.:
>UPDATE foo f SET f = ..;
> would resol
Merlin Moncure writes:
> On Wed, Oct 15, 2014 at 3:48 AM, Atri Sharma wrote:
>> Thanks for the links, but this patch only targets SET(*) case, which, if I
>> understand correctly, the patch you mentioned doesn't directly handle (If I
>> understand correctly, the target of the two patches is diffe
On Fri, Oct 17, 2014 at 10:10 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Oct 17, 2014 at 9:55 AM, Marko Tiikkaja wrote:
>>> I don't know about Tom, but I didn't like that:
>>> http://www.postgresql.org/message-id/5364c982.7060...@joh.to
>
>> Hm, I didn't understand your objection:
>
Marko Tiikkaja writes:
> local:marko=#* create table foo(f int);
> CREATE TABLE
> local:marko=#* update foo f set f=1;
> UPDATE 0
> This query would change meaning with your suggestion.
I think it wouldn't; Merlin is proposing that f would be taken as the
field name. A more realistic objection
On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> local:marko=#* create table foo(f int);
>> CREATE TABLE
>> local:marko=#* update foo f set f=1;
>> UPDATE 0
>
>> This query would change meaning with your suggestion.
>
> I think it wouldn't; Merlin is proposing that f
Pavel Stehule wrote:
> do you know, so this feature is a proprietary and it is not based
> on ANSI/SQL? Any user, that use this feature and will to port to
> other database will hate it.
I remember that Sybase ASE allowed a trailing comma within the
parentheses of a table definition, which was h
Merlin Moncure writes:
> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
>> I think it wouldn't; Merlin is proposing that f would be taken as the
>> field name. A more realistic objection goes like this:
>>
>> create table foo(f int, g int);
>> update foo x set x = (1,2); -- works
>> alter t
Merlin, glad you tried it.
We take the query plan exactly as given by the planner, decide whether to JIT
or to punt depending on the cost. If we punt, it goes back to pg executor. If
we JIT, and if we could not proceed (usually of some operators we haven't
implemented yet), we again punt. Once
On Fri, Oct 17, 2014 at 10:30 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Fri, Oct 17, 2014 at 10:16 AM, Tom Lane wrote:
>>> I think it wouldn't; Merlin is proposing that f would be taken as the
>>> field name. A more realistic objection goes like this:
>>>
>>> create table foo(f int, g
On Fri, Oct 17, 2014 at 10:47 AM, CK Tan wrote:
> Merlin, glad you tried it.
>
> We take the query plan exactly as given by the planner, decide whether to JIT
> or to punt depending on the cost. If we punt, it goes back to pg executor. If
> we JIT, and if we could not proceed (usually of some op
On Oct 17, 2014 6:16 PM, "Tom Lane" wrote:
> A more realistic objection goes like this:
>
> create table foo(f int, g int);
> update foo x set x = (1,2); -- works
> alter table foo add column x int;
> update foo x set x = (1,2,3); -- no longer works
>
> It's not a real good thing if a column add
Now that we have the create hash index warning in 9.5, I realized that
we don't warn about hash indexes with PITR, only crash recovery and
streaming. This patch fixes that.
Is the wording "cannot be used" too vague. The CREATE INDEX manual
page has the words "give wrong answers to queries", whic
Dag-Erling Smørgrav wrote:
> Michael Paquier writes:
> > Please note that new features can only be added to the version
> > currently in development, aka 9.5.
>
> I understand this policy. However, this new feature a) has absolutely
> no impact unless the admin makes a conscious decision to use
Bruce Momjian wrote
> Now that we have the create hash index warning in 9.5, I realized that
> we don't warn about hash indexes with PITR, only crash recovery and
> streaming. This patch fixes that.
>
> Is the wording "cannot be used" too vague. The CREATE INDEX manual
> page has the words "give
Rushabh Lathia writes:
> pg_dump binary-upgrade fail with segmentation fault for type without
> element.
Ooops.
> Looking further into code I found that rather then fetching typrelid, we can
> use the already stored typrelid from TypeInfo structure.
Agreed. Patch committed, thanks!
David G Johnston writes:
> The question is whether we explain the implications of not being WAL-logged
> in an error message or simply state the fact and let the documentation
> explain the hazards - basically just output:
> "hash indexes are not WAL-logged and their use is discouraged"
+1. The
Alvaro Herrera writes:
> Dag-Erling Smørgrav wrote:
>> I understand this policy. However, this new feature a) has absolutely
>> no impact unless the admin makes a conscious decision to use it and b)
>> will make life much easier for everyone if a POODLE-like vulnerability
>> is discovered in TLS.
CK Tan writes:
> The bigint sum,avg,count case in the example you tried has some optimization.
> We use int128 to accumulate the bigint instead of numeric in pg. Hence the
> big speed up. Try the same query on int4 for the improvement where both pg
> and vitessedb are using int4 in the executio
Hi, Tom,
Sorry for double post to you.
Feng
-- Forwarded message --
From: Feng Tian
Date: Fri, Oct 17, 2014 at 10:29 AM
Subject: Re: [HACKERS] Vitesse DB call for testing
To: Tom Lane
Hi, Tom,
I agree using that using int128 in stock postgres will speed up things
too. On th
CK,
Before we go any further on this, how is Vitesse currently licensed?
last time we talked it was still proprietary. If it's not being
open-sourced, we likely need to take discussion off this list.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailin
On 2014-10-17 17:14:16 +0530, Amit Kapila wrote:
> On Tue, Oct 14, 2014 at 11:34 AM, Amit Kapila
> wrote:
> >
> >
> > I am not sure why we are seeing difference even though running
> > on same m/c with same configuration.
>
> I have tried many times, but I could not get the numbers you have
> pos
On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian wrote:
> I agree using that using int128 in stock postgres will speed up things too.
> On the other hand, that is only one part of the equation. For example, if
> you look at TPCH Q1, the int128 "cheating" does not kick in at all, but we
> are 8x faste
On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
> Well, that's pretty much cheating: it's too hard to disentangle what's
> coming from JIT vs what's coming from using a different accumulator
> datatype. If we wanted to depend on having int128 available we could
> get that speedup with a couple hours
On Fri, Oct 17, 2014 at 1:21 PM, Peter Geoghegan wrote:
> On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian wrote:
>> I agree using that using int128 in stock postgres will speed up things too.
>> On the other hand, that is only one part of the equation. For example, if
>> you look at TPCH Q1, the in
Andres Freund writes:
> On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
>> Well, that's pretty much cheating: it's too hard to disentangle what's
>> coming from JIT vs what's coming from using a different accumulator
>> datatype. If we wanted to depend on having int128 available we could
>> get tha
On Fri, Oct 17, 2014 at 12:56:52PM -0400, Tom Lane wrote:
> David G Johnston writes:
> > The question is whether we explain the implications of not being WAL-logged
> > in an error message or simply state the fact and let the documentation
> > explain the hazards - basically just output:
> > "hash
Happy to contribute to that decision :-)
On Fri, Oct 17, 2014 at 11:35 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
>>> Well, that's pretty much cheating: it's too hard to disentangle what's
>>> coming from JIT vs what's coming from using a differ
On 2014-10-16 20:22:24 -0400, Robert Haas wrote:
> On Thu, Oct 16, 2014 at 6:53 PM, Andres Freund wrote:
> > When using shared_buffers = 96GB there's a performance benefit, but not
> > huge:
> > master (f630b0dd5ea2de52972d456f5978a012436115e): 153621.8
> > master + LW_SHARED + lockl
On 09/14/2014 06:32 PM, Peter Eisentraut wrote:
On 9/12/14 3:13 PM, Andreas 'ads' Scherbaum wrote:
Of course a general rule how to link to WP would be nice ...
I think Wikipedia links should be avoided altogether. We can assume
that readers are technically proficient to look up general techni
Kevin Grittner wrote:
> Unless someone else wants to pick it up, I'll manage this one.
> Since there was no previous warning, I'll allow a grace day for the
> cut-off on submissions for this CF; if it isn't registered in the
> web application 24 hours after this email, I will move it to the
> ne
On Mon, Sep 15, 2014 at 4:37 AM, Marko Tiikkaja wrote:
>
> I've changed the patch back to ignore signatures when not using the
> decrypt_verify() functions in the attached.
Hi Marko,
This patch needs a rebase now that the armor header patch has been
committed.
Thanks,
Jeff
Following up something Pavel wrote, I notice that json_agg() and
json_object_agg() are both marked as immutable, even though they invoke
IO functions, while json_object is marked stable, even though it does
not, and can probably be marked as immutable. Mea maxima culpa.
I'm not sure what we sh
On 10/16/14 9:45 AM, Stephen Frost wrote:
> Alright, coming back to this, I have to ask- how are matviews different
> from views from the SQL standard's perspective? I tried looking through
> the standard to figure it out (and I admit that I probably missed
> something), but the only thing appears
On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan wrote:
> Following up something Pavel wrote, I notice that json_agg() and
> json_object_agg() are both marked as immutable, even though they invoke IO
> functions, while json_object is marked stable, even though it does not, and
> can probably be mar
A little while back some users started complaining that the contrib module
I develop (MADlib) was failing to build with the following error:
--
/usr/include/postgresql/9.2/server/port.h:480:32: error: declaration of
'char* mkdtemp(char*)' has a different exception specifier
/usr/include/stdlib
Hi,
Consider the following queries.
create table t(i int, j int, k int, t text);
insert into t select i, i % 100, i % 1000, 'AABBCCDD' || i from
generate_series(1, 100) i;
ftian=# explain select count(distinct j) from t group by t, i;
QUERY PLAN
---
On Fri, Oct 17, 2014 at 1:44 PM, Merlin Moncure wrote:
> Is it too late to change them? Either way, it seems fairly
> implausible someone would come up with a case to stick json_agg(), or
> any aggregate function really, inside of an index. So it's not exactly
> the crime of the century.
Indexes
Merlin Moncure wrote:
> On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan wrote:
> > Following up something Pavel wrote, I notice that json_agg() and
> > json_object_agg() are both marked as immutable, even though they invoke IO
> > functions, while json_object is marked stable, even though it does
On 10/17/14, 4:31 AM, David G Johnston wrote:
Since the standard doesn't distinguish between read and write aspects of the
object types there isn't a safe way to add matviews to the information
schema that doesn't violate the intent of the provided view. If the
application/users wants to support
Alvaro Herrera writes:
> Merlin Moncure wrote:
>> On Fri, Oct 17, 2014 at 3:03 PM, Andrew Dunstan wrote:
>>> Following up something Pavel wrote, I notice that json_agg() and
>>> json_object_agg() are both marked as immutable, even though they invoke IO
>>> functions, while json_object is marked s
Hi,
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the index was being used *all the
time*. However, after looking into our queries more closely, it turns
o
Marko Tiikkaja writes:
> This week we had one of the most annoying problems I've ever encountered
> with postgres. We had a big index on multiple columns, say, foo(a, b,
> c). According to pg_stat_all_indexes the index was being used *all the
> time*. However, after looking into our queries
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the index was being used *all the
time*. However,
Marko Tiikkaja writes:
> On 10/17/14, 11:47 PM, Tom Lane wrote:
>> Marko Tiikkaja writes:
>>> So what I'd like to have is a way to be able to distinguish between
>>> indexes being used to answer queries, and ones being only used for stats
>>> lookups during planning.
>> Why? Used is used.
> Be
On 10/17/14, 4:49 PM, Marko Tiikkaja wrote:
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
This week we had one of the most annoying problems I've ever encountered
with postgres. We had a big index on multiple columns, say, foo(a, b,
c). According to pg_stat_all_indexes the i
Caleb Welton writes:
> A little while back some users started complaining that the contrib module
> I develop (MADlib) was failing to build with the following error:
> /usr/include/postgresql/9.2/server/port.h:480:32: error: declaration of
> 'char* mkdtemp(char*)' has a different exception specifi
On 10/17/14, 11:59 PM, Tom Lane wrote:
Marko Tiikkaja writes:
On 10/17/14, 11:47 PM, Tom Lane wrote:
Marko Tiikkaja writes:
So what I'd like to have is a way to be able to distinguish between
indexes being used to answer queries, and ones being only used for stats
lookups during planning.
On 10/16/14, 11:48 PM, David Johnston wrote:
We might as well allow a final trailing (or initial leading) comma on a
values list at the same time:
do you know, so this feature is a proprietary and it is not based on
ANSI/SQL? Any user, that use this feature and will to po
Marko Tiikkaja writes:
> On 10/17/14, 11:59 PM, Tom Lane wrote:
>> Well, the index might've been getting used in queries too in a way that
>> really only involved the first column. I think you're solving the wrong
>> problem here. The right problem is how to identify indexes that are
>> being us
Jim Nasby writes:
> As I originally posted, if we're going to do this I think we should do it
> *EVERYWHERE* commas are used as delimiters, save COPY input and output. Or we
> should at least get close to doing it everywhere. I think the only way things
> could get more annoying is if we accept
On 10/16/14, 11:46 PM, David G Johnston wrote:
Tom Lane-2 wrote
Something else mentioned was that once you start a smart shutdown you
have no good way (other than limited ps output) to see what the shutdown
is waiting on. I'd like to have some way to get back into the database
to see what's goin
> It has been registered now
> (https://commitfest.postgresql.org/action/patch_view?id=1585). I've got
> an updated version of the patch with the documentation fix.
>
Looks like the patch is all good. I'm marking as ready for commiter.
On a side note, i'm noticing from http://en.wikipedia.org/wik
On 10/18/14, 12:15 AM, Tom Lane wrote:
Marko Tiikkaja writes:
I think there's a big difference between "this index was used to look up
stuff for planning" and "this index was used to answer queries quickly".
I think that's utter nonsense.
Well you probably know a bit more about the optimize
> The query,
> select count(distinct j) from t group by t, i;
>
> runs for 35 seconds. However, if I change the query to,
> select count(distinct j) from t group by i, t; -- note switching the
> ordering
> select count(distinct j) from t group by decode(t, 'escape'), i; -- convert
> t to bytea
>
On Sat, Oct 18, 2014 at 5:10 AM, Feng Tian wrote:
> Hi,
>
> Consider the following queries.
>
> create table t(i int, j int, k int, t text);
> insert into t select i, i % 100, i % 1000, 'AABBCCDD' || i from
> generate_series(1, 100) i;
>
> ftian=# explain select count(distinct j) from t group
On Sat, Oct 18, 2014 at 12:35 PM, Tatsuo Ishii wrote:
> > The query,
> > select count(distinct j) from t group by t, i;
> >
> > runs for 35 seconds. However, if I change the query to,
> > select count(distinct j) from t group by i, t; -- note switching the
> > ordering
> > select count(distinct
* Nicolas Barbier (nicolas.barb...@gmail.com) wrote:
> 2014-10-16 Stephen Frost :
>
> > Alright, coming back to this, I have to ask- how are matviews different
> > from views from the SQL standard's perspective?
>
> Matviews that are always up to date when you access them are
> semantically exact
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/16/14 9:45 AM, Stephen Frost wrote:
> > Alright, coming back to this, I have to ask- how are matviews different
> > from views from the SQL standard's perspective? I tried looking through
> > the standard to figure it out (and I admit that I prob
On Fri, Oct 17, 2014 at 3:34 AM, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-10-16 10:06:59 -0400, Tom Lane wrote:
> >> No, it wasn't. I'm not convinced either that that patch will get in at
> >> all, or that it has to have regression tests of that particular form,
> >> or that such a s
David Rowley writes:
> On Fri, Oct 17, 2014 at 3:34 AM, Tom Lane wrote:
>> I don't want to go there. It would be a lot better to expend the effort
>> on a better regression testing infrastructure that wouldn't *need*
>> bitwise-identical output across platforms. (mysql is ahead of us in that
>>
Hi, David,
Yes, switch sorting order would loose an interesting order so if user
dictates order by t, i; planner need to resort to its cost model.
Estimating cardinality of groupby is a much bigger topic than this thread.
I feel sorting string as if it is bytea is particularly interesting. I am
On Thu, Oct 16, 2014 at 12:01:28PM -0400, Stephen Frost wrote:
> This started out as a request for a non-superuser to be able to review
> the log files without needing access to the server. Now, things can
> certainly be set up on the server to import *all* logs and then grant
> access to a non-su
On Fri, Oct 17, 2014 at 6:25 PM, Feng Tian wrote:
> I feel sorting string as if it is bytea is particularly interesting. I am
> aware Peter G's patch and I think it is great, but for this sort agg case,
> first, I believe it is still slower than sorting bytea, and second, Peter
> G's patch depend
1 - 100 of 109 matches
Mail list logo
