On Thu, Mar 15, 2012 at 8:48 PM, Alvaro Herrera
> What Peter proposed seems to me pretty reasonable, in the sense that it
> should be possible to come up with a function that creates some text
> representation of whatever is in pg_statistic, and another function to
> load that data into the new ca
On 2012-03-15 21:45, Robert Haas wrote:
On Wed, Mar 14, 2012 at 11:10 AM, Kohei KaiGai wrote:
If it is ready to commit, please remember the credit to Yeb's volunteer
on this patch.
Done.
In the patch with copy-editing documentation following that commit, at
"in at their option", s/in// ? Als
On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
> On 15 March 2012 22:06, Dimitri Fontaine wrote:
> > Dimitri Fontaine writes:
> >>> At this moment in time, CTAS is still outstanding. Is the plan to try
> >>> to get that in for this release, or as an enhancement in 9.3?
> >>
> >> The
* Thom Brown wrote:
I don’t understand how functions can return a type of “command
trigger”. This certainly works, but I’ve never seen a type consisting
of more than one word. Could you explain this for me? This is also
postgres=> with types (name) as
postgres-> (select format_type(oid, NUL
On 16 March 2012 08:13, Andres Freund wrote:
> On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
>> Looks like the ctas-on-command-triggers-01.patch patch needs re-basing.
> I can do that - but imo the other patch (not based on the command triggers
> stuff) is the relevant for now as this
I have a plan to support 'Create index on foreign table' for 9.3. Here
is my plan.
The index creation is supported for a flat file such as CSV and a remote
table on a RDB e.g., Postgres using CREATE INDEX. (I thought using a
new statement, CREATE FOREIGN INDEX, at first, but I think that CREATE
Hi,
On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
> I tricked that in the grammar, the type is called cmdtrigger but I
> though it wouldn't be a good choice for the SQL statement.
Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am
squeamish.
> + oid |
On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote:
> On 16 March 2012 08:13, Andres Freund wrote:
> > On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
> >> Looks like the ctas-on-command-triggers-01.patch patch needs re-basing.
> >
> > I can do that - but imo the other patch (not ba
On 15 March 2012 21:58, Dimitri Fontaine wrote:
> Thom Brown writes:
>> I don’t understand how functions can return a type of “command
>> trigger”. This certainly works, but I’ve never seen a type consisting
>> of more than one word. Could you explain this for me? This is also
>
> I tricked th
On 16 March 2012 08:45, Andres Freund wrote:
> On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote:
>> On 16 March 2012 08:13, Andres Freund wrote:
>> > On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
>> >> Looks like the ctas-on-command-triggers-01.patch patch needs re-basing.
>> >
On Thu, Mar 15, 2012 at 11:01 PM, Daniel Farina wrote:
> Okay, well, I believe there is a race in handling common
> administrative signals that *might* possibly matter. In the past,
> pg_cancel_backend was superuser only, which is a lot like saying "only
> available to people who can be the postg
On Friday, March 16, 2012 09:55:10 AM Thom Brown wrote:
> On 16 March 2012 08:45, Andres Freund wrote:
> > On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote:
> >> On 16 March 2012 08:13, Andres Freund wrote:
> >> > On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote:
> >> >> Looks like
Andres Freund writes:
> On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
>> I tricked that in the grammar, the type is called cmdtrigger but I
>> though it wouldn't be a good choice for the SQL statement.
> Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am
On 16.03.2012 10:44, Etsuro Fujita wrote:
> I have a plan to support 'Create index on foreign table' for 9.3. Here
> is my plan.
>
> The index creation is supported for a flat file such as CSV and a remote
> table on a RDB e.g., Postgres using CREATE INDEX. (I thought using a
> new statement, CR
On Thursday, March 15, 2012 07:38:38 AM Jeff Davis wrote:
> On Wed, 2012-03-14 at 10:26 +0100, Andres Freund wrote:
> > On Wednesday, March 14, 2012 05:23:03 AM Jeff Davis wrote:
> > > On Tue, 2012-03-13 at 09:42 +0100, Andres Freund wrote:
> > > > for recursively everything in dir:
> > > >posi
Hi all,
During writing pgsql_fdw codes, I noticed that exprCollation rejects
non-Expr nodes with error "unrecognized node type: %d". Is this
intentional behavior, or can it return InvalidOid for unrecognized nodes
like exprInputCollation?
Background information: I use exprCollation with expressi
Thom Brown writes:
> Note: incremental patch attached for the following section...
Applied, thanks!
> I don’t know if this was a problem before that I didn’t spot
> (probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE
> show a command tag of ALTER TABLE for ALTER FOREIGN TABLE s
On 16 March 2012 11:42, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Specific command triggers on ALTER VIEW don’t work at all:
>
> Can't reproduce, and that's already part of the regression tests.
This was a problem my side (a mistake I made previously) as I hadn't
added this particular one
Thom Brown writes:
> Okay, I shalln't do any more testing until the next patch. I should
> probably have worked on automating my tests more, but never got round
> to it.
make installcheck :)
That said, your test allow to spot OID problems that we can't add in the
regression tests (OID being t
On 16 March 2012 12:07, Dimitri Fontaine wrote:
> Thom Brown writes:
>> Okay, I shalln't do any more testing until the next patch. I should
>> probably have worked on automating my tests more, but never got round
>> to it.
>
> make installcheck :)
>
> That said, your test allow to spot OID prob
(2012/03/16 18:58), Heikki Linnakangas wrote:
> On 16.03.2012 10:44, Etsuro Fujita wrote:
>> I have a plan to support 'Create index on foreign table' for 9.3. Here
>> is my plan.
>>
>> The index creation is supported for a flat file such as CSV and a remote
>> table on a RDB e.g., Postgres using C
Peter Eisentraut writes:
>> Is there a reason for us not to add an HINT: "user" is a reserved
>> keyword or something like that, other than nobody having been interested
>> in doing the work?
>
> If that were easily possible, we could just recognize 'user' as an
> identifier in this context and av
Shigeru HANADA writes:
> During writing pgsql_fdw codes, I noticed that exprCollation rejects
> non-Expr nodes with error "unrecognized node type: %d". Is this
> intentional behavior, or can it return InvalidOid for unrecognized nodes
> like exprInputCollation?
Doesn't seem to me that asking for
On 16.03.2012 14:50, Dimitri Fontaine wrote:
Peter Eisentraut writes:
Is there a reason for us not to add an HINT: "user" is a reserved
keyword or something like that, other than nobody having been interested
in doing the work?
If that were easily possible, we could just recognize 'user' as a
Excerpts from Bruce Momjian's message of vie mar 16 00:04:06 -0300 2012:
>
> On Tue, Mar 13, 2012 at 02:35:02PM -0300, Alvaro Herrera wrote:
> >
> > Excerpts from Bruce Momjian's message of mar mar 13 14:00:52 -0300 2012:
> > >
> > > On Tue, Mar 06, 2012 at 04:39:32PM -0300, Alvaro Herrera wrot
Excerpts from Alvaro Herrera's message of vie mar 16 10:36:11 -0300 2012:
> > Now I am confused. Where do you see the word "hint" used by
> > HEAP_XMAX_EXCL_LOCK and HEAP_XMAX_SHARED_LOCK. These are tuple infomask
> > bits, not hints, meaning they are not optional or there just for
> > performa
Andres Freund writes:
> On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
>> I tricked that in the grammar, the type is called cmdtrigger but I
>> though it wouldn't be a good choice for the SQL statement.
> Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am
2012/3/16 Etsuro Fujita :
> I have a plan to support 'Create index on foreign table' for 9.3. Here
> is my plan.
Very interesting idea, but...
> The index creation is supported for a flat file such as CSV and a remote
> table on a RDB e.g., Postgres using CREATE INDEX.
Why do you limit the targ
On Friday, March 16, 2012 02:50:55 PM Tom Lane wrote:
> While I'm looking at the grammar ... it also seems like a serious
> PITA from a maintenance standpoint that we're now going to have to
> adjust the CREATE COMMAND TRIGGER productions every time somebody
> thinks of a new SQL command.
I don't
Andres Freund writes:
> On Friday, March 16, 2012 02:50:55 PM Tom Lane wrote:
>> While I'm looking at the grammar ... it also seems like a serious
>> PITA from a maintenance standpoint that we're now going to have to
>> adjust the CREATE COMMAND TRIGGER productions every time somebody
>> thinks of
On Thu, Mar 15, 2012 at 11:09 PM, Bruce Momjian wrote:
> On Tue, Mar 13, 2012 at 01:46:24PM -0400, Robert Haas wrote:
>> On Mon, Mar 12, 2012 at 3:28 PM, Simon Riggs wrote:
>> > I agree with you that some worst case performance tests should be
>> > done. Could you please say what you think the wo
Heikki Linnakangas writes:
> Accepting the keyword in such a context seems much harder to me than
> providing a hint. To accept the keyword, you'd need a lot of changes to
> the grammar, but for the hint, you just need some extra code in
> yyerror(). Mind you, if it's a hint, it doesn't need to
Tom Lane writes:
> Multi-word type names are a serious pain in the ass; they require
> hackery in a lot of places. We support the ones that the SQL spec
> requires us to, but I will object in the strongest terms to inventing
> any that are not required by spec. I object in even stronger terms to
I wrote:
> So I now propose reverting the earlier two patches (but not their
> regression test cases of course) and instead hacking MergeAppend plan
> building as per (2).
Attached is a draft patch for that. There are several things going on
here:
* Revert the preceding two patches (except for t
On Fri, Mar 16, 2012 at 7:42 AM, Dimitri Fontaine
wrote:
>> I don’t know if this was a problem before that I didn’t spot
>> (probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE
>> show a command tag of ALTER TABLE for ALTER FOREIGN TABLE statements
>> where the column is renamed:
Robert Haas writes:
> there has to be some way to do that without breaking command triggers.
Sure, special case the switch branch in utility.c so as to return a
different command tag for ALTER TABLE and ALTER FOREIGN TABLE. For
precedents, see AlterObjectTypeCommandTag(ObjectType objtype) and
On Fri, Mar 16, 2012 at 6:25 AM, Andres Freund wrote:
>> > How are the results with sync_file_range(fd, 0, 0,
>> > SYNC_FILE_RANGE_WRITE)?
>> That is much faster than using fadvise. It goes down to ~2s.
>
>> Unfortunately, that's non-portable. Any other ideas? 6.5s a little on
>> the annoying side
On Friday, March 16, 2012 04:47:06 PM Robert Haas wrote:
> On Fri, Mar 16, 2012 at 6:25 AM, Andres Freund wrote:
> >> > How are the results with sync_file_range(fd, 0, 0,
> >> > SYNC_FILE_RANGE_WRITE)?
> >>
> >> That is much faster than using fadvise. It goes down to ~2s.
> >>
> >> Unfortunately
Dimitri Fontaine writes:
> Tom Lane writes:
>> If you think "cmdtrigger" isn't a good name maybe you should have
>> picked a different one to start with.
> Well, I think it's a good internal name. I'm not too sure about exposing
> it, the only reason why it's a good name is because it's a single
On Fri, Mar 16, 2012 at 11:58:29AM +0200, Heikki Linnakangas wrote:
> On 16.03.2012 10:44, Etsuro Fujita wrote:
> > I have a plan to support 'Create index on foreign table' for 9.3.
> > Here is my plan.
> >
> > The index creation is supported for a flat file such as CSV and a
As others, I don't s
On tor, 2012-03-15 at 16:36 -0300, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of jue mar 15 16:25:53 -0300 2012:
> > On sön, 2012-02-19 at 20:10 +0100, Pavel Stehule wrote:
> > > I found so this extremely simple patch should be useful.
> > >
> > > It helps for pattern SELECT
On Fri, 2012-03-16 at 11:25 +0100, Andres Freund wrote:
> > I take that back. There was something wrong with my test -- fadvise
> > helps, but it only takes it from ~10s to ~6.5s. Not quite as good as I
> > hoped.
> Thats surprising. I wouldn't expect such a big difference between fadvise +
> sync
Here is a patch for being able to rename constraints of domains. It
goes on top of the previously committed patch for renaming table
constraints.
diff --git a/doc/src/sgml/ref/alter_domain.sgml b/doc/src/sgml/ref/alter_domain.sgml
index 2511a12..c59975a 100644
--- a/doc/src/sgml/ref/alter_domain.s
Peter Eisentraut writes:
> On tor, 2012-03-15 at 16:36 -0300, Alvaro Herrera wrote:
>> Excerpts from Peter Eisentraut's message of jue mar 15 16:25:53 -0300 2012:
>>> Isn't that just a subset of what I had proposed?
>>> http://archives.postgresql.org/message-id/1328820579.11241.4.ca...@vanquo.pezo
On Thu, Mar 15, 2012 at 09:18:36PM +0700, Stuart Bishop wrote:
> On Thu, Mar 15, 2012 at 9:01 PM, Stuart Bishop
> wrote:
>
> > Yes, it is there. I can see the library with the new name of
> > plpython2.so, not the old plpython.so from 8.4. createlang installs
> > the language just fine if I buil
On Fri, Mar 16, 2012 at 03:10:05PM +0700, Stuart Bishop wrote:
> > I have repeatedly upgraded from 9.0.X to 9.1.3 and am seeing no
> > failures. The big question is what are you doing that is causing the
> > plpython_call_handler() function to be dumped? That is an internal
> > function. What is
On Fri, Mar 16, 2012 at 10:40:01AM -0300, Alvaro Herrera wrote:
>
> Excerpts from Alvaro Herrera's message of vie mar 16 10:36:11 -0300 2012:
>
> > > Now I am confused. Where do you see the word "hint" used by
> > > HEAP_XMAX_EXCL_LOCK and HEAP_XMAX_SHARED_LOCK. These are tuple infomask
> > > b
On Fri, Mar 16, 2012 at 10:08:07AM -0400, Robert Haas wrote:
> On Thu, Mar 15, 2012 at 11:09 PM, Bruce Momjian wrote:
> > On Tue, Mar 13, 2012 at 01:46:24PM -0400, Robert Haas wrote:
> >> On Mon, Mar 12, 2012 at 3:28 PM, Simon Riggs wrote:
> >> > I agree with you that some worst case performance
I have a query where the LIMIT clause is incorrectly reducing the cost
of the query. This results in queries doing LIMIT m run much longer
when m is small (e.g. 1-3) than if m is larger. (PG 9.0) (And yes,
ANALYZE was run and, no, increasing stats_target for the columns
doesn't help).
Notice that
Excerpts from Bruce Momjian's message of vie mar 16 15:22:05 -0300 2012:
>
> On Fri, Mar 16, 2012 at 10:08:07AM -0400, Robert Haas wrote:
> > On Thu, Mar 15, 2012 at 11:09 PM, Bruce Momjian wrote:
> > > On Tue, Mar 13, 2012 at 01:46:24PM -0400, Robert Haas wrote:
> > >> On Mon, Mar 12, 2012 at 3
On Sat, Mar 17, 2012 at 12:54 AM, Bruce Momjian wrote:
> Well, it will because, by creating the symlink, you allowed this
> function to be restored into the new database, and it isn't properly
> hooked to the plpython language. I wonder if you should just delete it
> because I believe you alread
On Sat, Mar 17, 2012 at 01:57:29AM +0700, Stuart Bishop wrote:
> On Sat, Mar 17, 2012 at 12:54 AM, Bruce Momjian wrote:
>
> > Well, it will because, by creating the symlink, you allowed this
> > function to be restored into the new database, and it isn't properly
> > hooked to the plpython langua
On 16 March 2012 16:26, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> If you think "cmdtrigger" isn't a good name maybe you should have
>>> picked a different one to start with.
>
>> Well, I think it's a good internal name. I'm not too sure about exposing
>> it, the only rea
Andres Freund writes:
> [ ctas-01.patch ]
I'm starting to look at this now. For a patch that's supposed to
de-complicate things, it seems pretty messy :-(
One thing I soon found is that it lacks support for EXPLAIN SELECT INTO.
That used to work, but now you get
regression=# explain select * i
On Friday, March 16, 2012 09:54:47 PM Tom Lane wrote:
> Andres Freund writes:
> > [ ctas-01.patch ]
>
> I'm starting to look at this now.
Great!
> For a patch that's supposed to de-complicate things, it seems pretty messy
:-(
Yea. It started out simple but never stopped getting more complicated
Simon Riggs writes:
> 2. We assume that if values do exist that they have rows uniformly
> distributed across the whole table like rungs on a ladder.
Well, yeah. That's sometimes wrong, but not always. In the absence
of evidence to the contrary, I think it's a better assumption than
most others
Andres Freund writes:
> One more thing I disliked quite a bit was the duplication of the EXECUTE
> handling. Do you see a way to deduplicate that?
Yeah, that's what's bugging me, too. I think a chunk of the problem is
that you're insisting on having control come back to CreateTableAs()
to perfo
On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
> Andres Freund writes:
> > One more thing I disliked quite a bit was the duplication of the EXECUTE
> > handling. Do you see a way to deduplicate that?
> Yeah, that's what's bugging me, too. I think a chunk of the problem is
> that you're ins
On Fri, 2012-03-16 at 18:25 +, Simon Riggs wrote:
> Any time we apply a LIMIT clause to a plan with a SeqScan or
> unqualified IndexScan, we shouldn't assume the scan will do less than
> say 10% of the table. It might, but its an unsafe assumption because
> as the selectivity decreases so does
Andres Freund writes:
> On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
>> I'm thinking that if the table creation
>> were to be moved into the tuple receiver's startup routine, we could
>> avoid needing to get control back between ExecutorStartup and
>> ExecutorRun, and then all that would
On Fri, Mar 16, 2012 at 9:39 PM, Jeff Davis wrote:
> On Fri, 2012-03-16 at 18:25 +, Simon Riggs wrote:
>> Any time we apply a LIMIT clause to a plan with a SeqScan or
>> unqualified IndexScan, we shouldn't assume the scan will do less than
>> say 10% of the table. It might, but its an unsafe a
On Thu, Mar 15, 2012 at 7:58 PM, Jeff Davis wrote:
> On Thu, 2012-03-15 at 19:36 -0400, Tareq Aljabban wrote:
> > When configuring postgreSQL, I'm adding the libraries needed to run
> > HDFS C API (libhdfs).
> >
>
> >From the information below, it looks like C++.
>
> >
> > ./configure --prefix=/
On Friday, March 16, 2012 10:52:55 PM Tom Lane wrote:
> Andres Freund writes:
> > On Friday, March 16, 2012 10:31:57 PM Tom Lane wrote:
> >> I'm thinking that if the table creation
> >> were to be moved into the tuple receiver's startup routine, we could
> >> avoid needing to get control back betw
On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
> outright kill a backend that they own (politely, with a SIGTERM),
> aborting any transactions in progress, including the idle transaction,
> and closing the socke
On Thu, Mar 15, 2012 at 11:46:04AM -0400, Bruce Momjian wrote:
> On Thu, Mar 15, 2012 at 11:15:42AM -0400, Andrew Dunstan wrote:
> > You're not the only person who could do that. I don't think this is
> > all down to you. It should just be understood that if the stats
> > format is changed, adjusti
Àlvaro told me he got a Spanish-language report that pg_upgrade
failed because it required pg_config, and pg_config is only supplied
with the devel packages.
I initially thought that it was a packaging problem, but I later
realized the pg_config is mostly developer settings, and that using
pg_conf
Excerpts from Bruce Momjian's message of vie mar 16 20:06:28 -0300 2012:
> Àlvaro told me he got a Spanish-language report that pg_upgrade
> failed because it required pg_config, and pg_config is only supplied
> with the devel packages.
>
> I initially thought that it was a packaging problem, but
On Fri, 2012-03-16 at 18:02 -0400, Tareq Aljabban wrote:
> Thanks for your response Jeff..
> It's true that libhdfs code resides under the c++ folder, but in all
> of the documentation, libhdfs is referred to as the C interface of
> HDFS.
> Now what you're saying makes sense.. that nothing guarant
On Fri, Mar 16, 2012 at 3:42 PM, Noah Misch wrote:
> On Thu, Mar 15, 2012 at 04:14:03PM -0700, Daniel Farina wrote:
>> Parallel to pg_cancel_backend, it'd be nice to allow the user to just
>> outright kill a backend that they own (politely, with a SIGTERM),
>> aborting any transactions in progress
On Fri, Mar 16, 2012 at 4:42 PM, Daniel Farina wrote:
> Hmm. Well, here's a patch that implements exactly that, I think,
That version had some screws loose due to some editor snafus.
Hopefully all better.
--
fdr
Implement-race-free-sql-originated-backend-cancellation-v3.patch.gz
Description:
On Fri, Mar 16, 2012 at 11:29 PM, Jeff Davis wrote:
> There is a lot of difference between those two. In particular, it looks
> like the problem you are seeing is coming from the background writer,
> which is not running during initdb.
The difference that comes to mind is that the postmaster fork
[used followup EACH-foreign-key.v4b.patch.bz2 for review]
On Wed, Mar 14, 2012 at 07:03:08PM +0100, Marco Nenciarini wrote:
> please find attached v4 of the EACH Foreign Key patch (formerly known
> also as Foreign Key Array).
> On Fri, Feb 24, 2012 at 09:01:35PM -0500, Noah Misch wrote:
> > > We
On Fri, Mar 16, 2012 at 3:16 PM, Tom Lane wrote:
>> So I now propose reverting the earlier two patches (but not their
>> regression test cases of course) and instead hacking MergeAppend plan
>> building as per (2).
As a wise man once said, "This is tricky stuff". I feel a better that
I got stuck
73 matches
Mail list logo
