On 11/16/12 12:20 AM, Craig Ringer wrote:
Not that implementing `hstore_to_json` is exactly hard, mind you, as a
quick search shows: https://gist.github.com/2318757
Both pulling hstore more firmly into core and adopting something like a
hstore_to_json call as the preferred UI for timing event
2012/11/20 Greg Smith :
> On 11/16/12 12:20 AM, Craig Ringer wrote:
>
>> Not that implementing `hstore_to_json` is exactly hard, mind you, as a
>> quick search shows: https://gist.github.com/2318757
>
>
> Both pulling hstore more firmly into core and adopting something like a
> hstore_to_json call
Kohei KaiGai wrote:
>>> This design tries to kill two-birds with one-stone.
>>> It enables to add multiple number of pseudo-columns,
>>> not only "rowid", and makes possible to push-down
>>> complex calculation of target list into external computing
>>> resource.
>>>
>>> For example, when user give
Robert Haas writes:
> I'm not opposed to the idea of being able to make extensions without
> files on disk work ... but I consider it a niche use case; the
> behavior we have right now works well for me and hopefully for others
> most of the time.
Apparently I'm not the only one doing extensions
Glad to see this patch hasn't been totally forgotten. Being able to use
indexes for regular expressions would be really cool!
Back in January, I asked for some high-level description of how the
algorithm works
(http://archives.postgresql.org/message-id/4f187d5c.30...@enterprisedb.com).
That's
On 2012-11-20 09:30:40 +0900, Michael Paquier wrote:
> On Mon, Nov 19, 2012 at 5:50 PM, Andres Freund wrote:
> > On 2012-11-19 16:28:55 +0900, Michael Paquier wrote:
> > > I am just looking at this patch and will provide some comments.
> > > By the way, you forgot the installation part of pg_receiv
Hi,
On 2012-11-19 19:50:32 -0500, Steve Singer wrote:
> On 12-11-18 11:07 AM, Andres Freund wrote:
> >I think we should provide some glue code to do this, otherwise people
> >will start replicating all the bugs I hacked into this... More
> >seriously: I think we should have support code here, no u
Hello,
I've started implementing a system for faster headline generation. WIP
patch is attached.
The idea is to make a new type currently called hltext (different
names welcome), that stores the text along with the lexization result.
It conceptually stores an array of tuples like
(word text, type
2012/11/15 Shigeru Hanada :
> Hi Kaigai-san,
>
> Sorry for delayed response. I updated the patch, although I didn't change
> any about timing issue you and Fujita-san concern.
>
> 1) add some FDW options for cost estimation. Default behavior is not
> changed.
> 2) get rid of array of libpq optio
On Monday, November 19, 2012 10:54 PM Heikki Linnakangas wrote:
> On 10.10.2012 17:54, Thom Brown wrote:
> > Hmm... I get something different. When I promote standby B, standby
> > C's log shows:
> >
> > The following problems are observed while testing of the patch.
> > Defect-1:
> >
> >
2012/11/19 Alvaro Herrera :
> Kohei KaiGai wrote:
>> Sorry, I missed the attached version.
>> Please use this revision.
>
> All those direct uses of object_access_hook make me think that the
> InvokeObjectAccessHook() macro we have is insufficient. Maybe we could
> have InvokeObjectAccessHookArg1(
Kohei KaiGai wrote:
> I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks, rather
> than doing all the stuffs with macros. It allows to use local variables,
> unlike
> macros; that has a risk of naming conflict with temporary variable for
> ObjectAccessPostCreate.
No objection
On Monday, November 19, 2012 9:07 PM Amit Kapila wrote:
> On Monday, November 19, 2012 8:36 PM Alvaro Herrera wrote:
> > Amit Kapila escribió:
> >
> > > The only point I can see against SET PERSISTENT is that other
> variants
> > of
> > > SET command can be used in
> > > transaction blocks means fo
2012/11/20 Albe Laurenz :
> Kohei KaiGai wrote:
This design tries to kill two-birds with one-stone.
It enables to add multiple number of pseudo-columns,
not only "rowid", and makes possible to push-down
complex calculation of target list into external computing
resource.
>>
>> The second hunk to alter.c does not apply anymore; please rebase.
>>
> OK,
Oops, I assumed the patch for ALTER RENAME TO reworks. Sorry.
2012/11/20 Alvaro Herrera :
> Kohei KaiGai wrote:
>
>> I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks,
>> rather
>> than doing all t
Kohei KaiGai wrote:
> Probably, it is helpful to provide a helper function that fetches an
attribute-
> number of pseudo "rowid" column from the supplied targetlist.
> If we have GetPseudoRowidColumn() at foreign/foreign.c, the avove
> routine can be rewritten as:
>
> static AttrNumber
> fileGetFo
2012-11-18 17:20 keltezéssel, Magnus Hagander írta:
On Tue, Oct 23, 2012 at 5:08 PM, Magnus Hagander wrote:
On Oct 23, 2012 4:52 PM, "Alvaro Herrera" wrote:
Boszormenyi Zoltan escribió:
Also, the check for conflict between -R and -x/-X is now removed.
The documentation for option -R has ch
2012-11-20 17:03 keltezéssel, Boszormenyi Zoltan írta:
2012-11-18 17:20 keltezéssel, Magnus Hagander írta:
The whole tar writing part of the code needs a lot more comments. It's
entirely unclear what the code does there. Why does the recovery.conf
writing code need to be split up in multiple lo
On 11/19/2012 06:24 PM, Stefan Kaltenbrunner wrote:
> Hi all!
>
>
> There will be planned hardware/software maintenance this tomorrow
> Tuesday (20th November 2012) from starting at 16:30 CET - affecting some
> redundant services (ftp and www mirrors) as well as the following public
> hosts:
>
>
On 19.11.2012 15:17, Pavel Stehule wrote:
I tested this patch and I can confirm, so this patch can increase
speed about 16-22% (depends on IO waits, load type).
Thanks for the review.
I spent some more time on this, continuing with the thought that perhaps
it would be better if get_str_from_v
I write my dll files in visual studio 2010.The dll file (name fservice.dll),
which has an external function, code write in c++ (VS2010, I have dll and lib
files)char * convert(char *)I
tested my fservice.dll in console application which called function in
this dll. It was work fine. I have a p
2012/11/20 Heikki Linnakangas :
> On 19.11.2012 15:17, Pavel Stehule wrote:
>>
>> I tested this patch and I can confirm, so this patch can increase
>> speed about 16-22% (depends on IO waits, load type).
>
>
> Thanks for the review.
>
> I spent some more time on this, continuing with the thought th
On Thu, Nov 15, 2012 at 8:56 PM, Abhijit Menon-Sen wrote:
> [ new patch ]
I went over this again today with a view to getting it committed, but
discovered some compiler warnings that look like this:
warning: cast to pointer from integer of different size
The problem seems to be that the binary
On 19 November 2012 16:25, Robert Haas wrote:
> Beyond that, I think much of the appeal of the extension feature is
> that it dumps as "CREATE EXTENSION hstore;" and nothing more. That
> allows you to migrate a dump between systems with different but
> compatible versions of the hstore and have
On Tue, 09 Oct 2012 16:44:07 +0200, Vik Reykja wrote:
I don't see Sébastien's message, but I made the same mistake in my patch.
Another one is attached with copyfuncs and equalfuncs. I did a grep for
DeallocateStmt and I don't believe I have missed anything else.
The patch looks pretty straig
On 2012-11-20 14:03:12 -0500, Robert Haas wrote:
> On Thu, Nov 15, 2012 at 8:56 PM, Abhijit Menon-Sen
> wrote:
> > [ new patch ]
>
> I went over this again today with a view to getting it committed, but
> discovered some compiler warnings that look like this:
>
> warning: cast to pointer from int
Heikki Linnakangas writes:
> * Add init_var_from_num() function. This is the same as
> set_var_from_num_nocopy in the original patch, but it doesn't require
> the caller to have called init_var() first. IMHO this makes the calling
> code slightly more readable. Also, it's now more evident what
On Tue, Nov 20, 2012 at 3:02 AM, Tomas Vondra wrote:
> 2) It's common to use upper-case names for macros, but trgm.h defines
>macro "iswordchr" - I see it's moved from trgm_op.c but maybe we
>could make it a bit more correct?
>
> 3) I see there are two '#ifdef KEEPONLYALNUM" blocks right
On Tue, Nov 20, 2012 at 2:29 PM, Andres Freund wrote:
> On 2012-11-20 14:03:12 -0500, Robert Haas wrote:
>> On Thu, Nov 15, 2012 at 8:56 PM, Abhijit Menon-Sen
>> wrote:
>> > [ new patch ]
>>
>> I went over this again today with a view to getting it committed, but
>> discovered some compiler warn
On 2012-11-20 15:06:58 -0500, Robert Haas wrote:
> On Tue, Nov 20, 2012 at 2:29 PM, Andres Freund wrote:
> > On 2012-11-20 14:03:12 -0500, Robert Haas wrote:
> >> On Thu, Nov 15, 2012 at 8:56 PM, Abhijit Menon-Sen
> >> wrote:
> >> > [ new patch ]
> >>
> >> I went over this again today with a vie
Andres Freund wrote:
> - I find using a default: clause in switches with enum types where everything
> is expected to be handled like the following a bad idea, this way the
> compiler won't warn you if youve missed case's which makes
> changing/extending code harder:
> switch (
On Tue, Nov 20, 2012 at 3:19 PM, Andres Freund wrote:
> I don't have a fundamental problem with it, but I don't think it's worth
> the cost. If you have variable sized (from the point of the compiler)
> values you either have more complex offset computations to the
> individual elements or one mor
hello
do you plan to support GiST?
Regards
Pavel
2012/11/20 Alexander Korotkov :
> On Tue, Nov 20, 2012 at 3:02 AM, Tomas Vondra wrote:
>>
>> 2) It's common to use upper-case names for macros, but trgm.h defines
>>macro "iswordchr" - I see it's moved from trgm_op.c but maybe we
>>could
On 2012-11-20 17:36:14 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
>
> > - I find using a default: clause in switches with enum types where
> > everything
> > is expected to be handled like the following a bad idea, this way the
> > compiler won't warn you if youve missed case's whic
On Thu, Nov 15, 2012 at 10:37 PM, Simon Riggs wrote:
> On 15 November 2012 22:21, Tom Lane wrote:
>
>>> Removing those 3 hints would give us 3 more flag bits (eventually, after
>>> we are sure they aren't just leftover), and it would also reduce the
>>> chance that a page is dirtied for no other
On 2012-11-20 15:47:25 -0500, Robert Haas wrote:
> On Tue, Nov 20, 2012 at 3:19 PM, Andres Freund wrote:
> > I don't have a fundamental problem with it, but I don't think it's worth
> > the cost. If you have variable sized (from the point of the compiler)
> > values you either have more complex of
Merlin Moncure writes:
> Hm, I wonder if you could squeeze two bits out. ISTM here are the
> interesting cases enumerated:
> 0: xmin unknown
> 1: xmin invalid
> 2: xmin valid, xmax unknown
> 3: xmin valid, xmax invalid
> 4: xmin valid, xmax valid
> Did I miss any?
Yes. xmin unknown, xmax unkno
On Tue, Nov 20, 2012 at 1:26 PM, Merlin Moncure wrote:
> In this sprawling thread on scaling issues [1], the topic meandered
> into StrategyGetBuffer() -- in particular the clock sweep loop. I'm
> wondering:
>
> *) If there shouldn't be a a bound in terms of how many candidate
> buffers you're al
Robert Haas writes:
> Here's a revised patch that takes the approach of just changing void *
> to Datum; it includes a bunch of other cleanups that I felt were
> worthwhile.
The comment in binaryheap.h says
* For a max-heap, the comparator must return -1 iff a < b, 0 iff a == b,
* and +1 iff a
On Tue, Nov 20, 2012 at 4:50 PM, Jeff Janes wrote:
> On Tue, Nov 20, 2012 at 1:26 PM, Merlin Moncure wrote:
>> In this sprawling thread on scaling issues [1], the topic meandered
>> into StrategyGetBuffer() -- in particular the clock sweep loop. I'm
>> wondering:
>>
>> *) If there shouldn't be a
On 11/20/2012 04:48 PM, Pavel Stehule wrote:
> 2012/11/20 Greg Smith :
>> On 11/16/12 12:20 AM, Craig Ringer wrote:
>>
>>> Not that implementing `hstore_to_json` is exactly hard, mind you, as a
>>> quick search shows: https://gist.github.com/2318757
>>
>> Both pulling hstore more firmly into core a
Hi.
A brief response to earlier messages in this thread:
1. I agree that it's a good idea to use Datum rather than void *.
2. I don't think it's worth getting rid of binaryheap_node.
3. I agree that it makes sense to go with what we have now (after
Robert's reworking of my patch) and reconside
Abhijit Menon-Sen writes:
>> While I'm thinking about it, why are the fields of a binaryheap_node
>> called "key" and "value"? That implies a semantics not actually used
>> here. Maybe "value1" and "value2" instead?
> Yes, I discussed this with Andres earlier (and considered ptr and value
> or
At 2012-11-20 22:55:52 -0500, t...@sss.pgh.pa.us wrote:
>
> BTW, I probably missed some context upthread, but why do we have two
> fields at all?
I would also have preferred to handle the nodeMergeAppend case using a
context pointer as you suggest, but Andres needs to store two pointers
in his hea
Hi Karl,
I signed on to review this patch for the current CF. Most of the
background for the patch seems to be in the message below, so I'm
going to respond to this one first.
On Fri, Sep 21, 2012 at 8:54 AM, Karl O. Pinc wrote:
> On 09/20/2012 12:24:49 PM, Karl O. Pinc wrote:
>
>> I've had probl
On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund wrote:
> Those aren't unexpected. Perhaps I should not make it a warning then...
>
> A short explanation:
>
> We can only decode tuples we see in the WAL when we already have a
> timetravel catalog snapshot before that transaction started. To build
>
On Wednesday, November 21, 2012 4:21 AM Jeff Janes wrote:
> On Tue, Nov 20, 2012 at 1:26 PM, Merlin Moncure
> wrote:
> > In this sprawling thread on scaling issues [1], the topic meandered
> > into StrategyGetBuffer() -- in particular the clock sweep loop. I'm
> > wondering:
> >
> >
> > *) Sinc
On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund wrote:
> On 2012-11-20 09:30:40 +0900, Michael Paquier wrote:
> > On Mon, Nov 19, 2012 at 5:50 PM, Andres Freund >wrote:
> > > On 2012-11-19 16:28:55 +0900, Michael Paquier wrote:
> > > > I am just looking at this patch and will provide some comments
On 2012-11-21 15:28:30 +0900, Michael Paquier wrote:
> On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund wrote:
>
> > On 2012-11-20 09:30:40 +0900, Michael Paquier wrote:
> > > Btw, here are some extra comments based on my progress, hope it will be
> > > useful for other people playing around with you
On 2012-11-21 14:57:08 +0900, Michael Paquier wrote:
> On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund wrote:
>
> > Those aren't unexpected. Perhaps I should not make it a warning then...
> >
> > A short explanation:
> >
> > We can only decode tuples we see in the WAL when we already have a
> > tim
On Wed, Nov 21, 2012 at 4:31 PM, Andres Freund wrote:
> On 2012-11-21 14:57:08 +0900, Michael Paquier wrote:
> > On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund >wrote:
> > > It implies that snapstate->nrrunning has lost touch with reality...
> > >
> > Yes, I can reproduce in 10-20 seconds in one
On 2012-11-21 14:57:08 +0900, Michael Paquier wrote:
> On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund wrote:
>
> > Those aren't unexpected. Perhaps I should not make it a warning then...
> >
> > A short explanation:
> >
> > We can only decode tuples we see in the WAL when we already have a
> > tim
On Wed, Nov 21, 2012 at 4:30 PM, Andres Freund wrote:
> On 2012-11-21 15:28:30 +0900, Michael Paquier wrote:
> > On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund >wrote:
> >
> > > On 2012-11-20 09:30:40 +0900, Michael Paquier wrote:
> > > > Btw, here are some extra comments based on my progress, ho
On 2012-11-21 16:47:11 +0900, Michael Paquier wrote:
> On Wed, Nov 21, 2012 at 4:30 PM, Andres Freund wrote:
>
> > On 2012-11-21 15:28:30 +0900, Michael Paquier wrote:
> > > On Tue, Nov 20, 2012 at 8:22 PM, Andres Freund > >wrote:
> > >
> > > > On 2012-11-20 09:30:40 +0900, Michael Paquier wrote:
54 matches
Mail list logo
