+ * CreateSharedInvalidationState
* Create and initialize the SI message buffer
*/
void
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
xPredicate(indexRel) != NIL)
{
index_close(indexRel, NoLock);
ReleaseSysCache(indexTuple);
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jul 9, 2013 at 12:50 PM, Kevin Grittner wrote:
>
> Thanks again! New patch attached.
>
After a couple of more attempts trying to break it, I mark this as
ready to go. One small question: why do we use multiple unique
indexes if exist? One index isn't enough?
--
On Sat, Jul 6, 2013 at 9:20 AM, Kevin Grittner wrote:
> Hitoshi Harada wrote:
>
>> Oops!
>
> Indeed. Thanks for the careful testing.
>
>> drop materialized view if exists mv;
>> drop table if exists foo;
>> create table foo(a, b) as values(1, 10);
>>
On Thu, Jul 4, 2013 at 2:18 AM, Hitoshi Harada wrote:
> For now, that's it. I'm going to dig more later.
>
After looking into rest of the change,
- TYPTYPE_DOMAIN is not supported. Why did you specifically disallow it?
- ParseFuncOrColumn now prohibits to find function returni
On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut wrote:
> On Thu, 2013-07-04 at 02:18 -0700, Hitoshi Harada wrote:
>> as someone suggested in the previous thread, it might be a variant of
>> CAST. CREATE CAST (hstore AS plpython2u) ? Or CREATE LANGUAGE TRANSFORM
>> mi
disk gets full. Or is that operation supposed to
be restricted by the security context you are adding?
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng all of these?
>
> I don't see any value in that. The data types they apply to are in
> contrib after all.
>
>
I guess his suggestion is contrib/transforms directory, not transforms
directory at top level. Stil you don't see value?
--
Hitoshi Harada
ema is inaccesible and undroppable:
>>
>
> and dropping the extension let the schema around
>
Hm? I guess '123' is not schema, but it's version.
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
y prohibiting the creation of a transform that
> affects functions that already exist.
However I don't see this prohibition of create transform if there is
already such function. You are not planning to address this issue?
For now, that's it. I'm going to dig more later.
Thanks,
Hitoshi Harada
On Thu, Jun 27, 2013 at 12:19 AM, Hitoshi Harada wrote:
>
>
>
> On Wed, Jun 26, 2013 at 1:38 AM, Kevin Grittner wrote:
>
>>
>
New version attached.
>>
>>
>> Will take another look.
>
>
>
Oops!
drop materialized view if exists mv;
drop table if
, and you may be confused with #1127, extensible
external toast tuple support.
--
Hitoshi Harada
On Thu, Jun 27, 2013 at 2:49 AM, Dimitri Fontaine wrote:
> Hi,
>
> Thanks a lot for your review!
>
> Some answers here, new version of the patch with fixes by tuesday.
>
> Hitoshi Harada writes:
> > - create template ex2, create extension ex2, alter template ex
ion_template and
pg_extension_control?
- Looks like both tables don't have toast tables. Some experiment gives:
ERROR: row is too big: size 8472, maximum size 8160
Thanks,
--
Hitoshi Harada
On Wed, Jun 26, 2013 at 1:38 AM, Kevin Grittner wrote:
> Hitoshi Harada wrote:
>
> > I spent a few hours to review the patch.
>
> Thanks!
>
> > As far as I can tell, the overall approach is as follows.
> >
> > - create a new temp heap as non-concurrent
On Tue, Jun 25, 2013 at 9:07 AM, Robert Haas wrote:
> On Fri, Jun 21, 2013 at 5:20 AM, Hitoshi Harada
> wrote:
> > If I don't miss something, the requirement for the CONCURRENTLY option
> is to
> > allow simple SELECT reader to read the matview concurrently while th
On Fri, Jun 21, 2013 at 3:20 AM, Craig Ringer wrote:
> On 06/21/2013 05:32 PM, Hitoshi Harada wrote:
>
> > I also later found that we are missing not only notion of '+' or '-',
> > but also notion of 'zero value' in our catalog. Per spec, RANGE
On Thu, Jun 20, 2013 at 12:19 AM, Etsuro Fujita wrote:
> > From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
>
> > I guess the patch works fine, but what I'm saying is it might be limited
> to
> > small use cases. Another instance of this that I can think of
On Fri, Jun 21, 2013 at 2:20 AM, Hitoshi Harada wrote:
>
>
>
> On Fri, Jun 14, 2013 at 9:05 AM, Kevin Grittner wrote:
>
>> Attached is a patch for REFRESH MATERIALIZED VIEW CONCURRENTLY for
>> 9.4 CF1. The goal of this patch is to allow a refresh without
>>
ue' in our catalog. Per spec, RANGE BETWEEN needs
to detect ERROR if the offset value is negative, but it is not always easy
if you think about interval, numeric types as opposed to int64 used in ROWS
BETWEEN.
Thanks,
--
Hitoshi Harada
with 'm', too, not only 'r'?
- I found two additional parameters on make_new_heap ugly, but couldn't
come up with better solution. Maybe we can pass Relation of old heap to
the function instead of Oid..
That's about it from me.
Thanks,
--
Hitoshi Harada
immediate shutdown? To me the current immediate
shutdown is reliable, in that it without doubt returns control back to
terminal, after killing postmaster at least.
Thanks,
--
Hitoshi Harada
tands it doesn't have critical issue, but more
generalized approach would be desirable. That said, I don't have strong
objection to the current patch, and just posting one thought to see if
others may have the same opinion.
Thanks,
--
Hitoshi Harada
don't see big problems in this patch other than how to
manage the pluggability, but it is a WIP patch anyway, so I'm going to mark
it as Returned with Feedback.
Thanks,
--
Hitoshi Harada
been done through grouping_planner, and
the parse tree is not necessarily representing the corresponding elements
at this point. I think it'd be better to see path keys to find out the
list of elements that may be removed, rather than SortClause, which would
be a more generalized approach.
Thanks,
--
Hitoshi Harada
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund wrote:
> On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> > On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund >wrote:
> >
> > >
> > > Here's the updated version. It shouldn't contain any obvious WIP p
want to avoid any
> per-tuple allocations.
>
>
I believe WinGetFuncArgInPartition is a bit slow if the offset is far from
the current row. So it might make sense to store the last-seen value, but
I'm not sure if we need to copy datum every time. I haven't looked into
the new patch.
Thanks,
--
Hitoshi Harada
optional builtin so that once the system is initialized the the plugin
should not go away. Anyway pluggable compression is off-topic here.
Thanks,
--
Hitoshi Harada
session id rather than
process id for the latter. I don't think SnapshotNow is the problem as
anyway executor is reading catalogs with that today.
Thanks,
Hitoshi
--
Hitoshi Harada
lso, try to
create a view on those expressions. I don't think it correctly preserves
it.
Thanks,
--
Hitoshi Harada
do like in date_in(). I
think to_date() should follow it because it is the entrance place to
check sanity.
Thanks,
--
Hitoshi Harada
to_date_check.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
ecial. plv8 also wanted this notion of
"function setting" before introducing find_function(), which natively
loads other JS functions that are defined via CREATE FUNCTION. Of
course it is not optimal, but it turned out it is not terribly slow.
Maybe it depends on language runtime. So f
On Fri, Oct 19, 2012 at 11:40 AM, Tom Lane wrote:
> Hitoshi Harada writes:
>> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane wrote:
>>> I'm not terribly comfortable with trying to use a PG_TRY block to catch
>>> an OOM error - there are too many ways that could bre
On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane wrote:
> I wrote:
>> Hitoshi Harada writes:
>>> If OOM happens during expand_table() in hash_search_with_hash_value()
>>> for RelationCacheInsert,
>
> the palloc-based allocator does throw
> errors. I think that when
her solutions?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Oct 1, 2012 at 3:30 PM, Hitoshi Harada wrote:
> lower address than field.
Ugh, s/lower/higher/
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
+ /* or it may not be what we expected... */
+ if (*str == '\0')
+ return DTERR_BAD_FORMAT;
+
field[nf] = str;
if (isdigit((unsigned char) *str))
{
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pg
ttr(). Of course some #ifdefs can fix that, but it seems
> annoying to make everyone do that. Maybe this could be reconsidered to
> reduce the impact on other projects.
>
But it's only add #include "access/htup_details.h"? I'd not argue
it's harmful unless I missed
echanism is used throughout postgres already and seems to work
> just fine.
>
Sure, but how do you know the type named "hstore" is what you know as
hstore? We don't have a global consensus a specific type name means
exactly what everyone thinks it is.
Thanks,
--
Hitoshi Hara
re-defined type or function oid macros, and I guess it is reasonable
for the external developers to hope to do such things.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
) in the same way, it's much nicer than having
additional binary + extension. Isn't it possible to do the same thing
above within the CLUSTER command? Maybe CLUSTER .. CONCURRENTLY?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
run ANALYZE first,
but it is too hard for a normal users to use it. We may need
quick-and-rough count(*) for this.
That is pretty much I have so far. I haven't read all the code nor
the standard, so I might be wrong somewhere.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Sep 14, 2012 at 12:55 PM, Tom Lane wrote:
> Hitoshi Harada writes:
>> I expected success in tname::regclass in the function chck(), but it
>> actually fails for your first run in the session.
>
> Really? Not for me.
>
> In the example as given, I see succe
ug in 9.2 or an
expected behavior in the new plan cache?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 17, 2012 at 7:26 AM, Volker Grabsch wrote:
> Hitoshi Harada schrieb:
>> On Wed, May 16, 2012 at 12:50 AM, Volker Grabsch
>> wrote:
>> > I propose the following general optimization: If all window
>> > functions are partitioned by the same first field
project tends to like the latter and it takes a little time but covers
more use cases.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ot;Yeah, that looks good", any more than I care if my mom
> thinks my latest web app is "very nice".
>
> I see now that the "Reviewing a Patch" wiki page explains this, but maybe
> this info should be pushed higher into the docs and web site; a "How can I
a good example, which invokes Python from FDW
routines though it is not using PL/Python.
http://multicorn.org/
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ound tcount parameter is said to
be applied to even INSERT. I believe people think that parameter is
to limit memory consumption when returning tuples thus it'd be applied
for only SELECT or DML with RETURNING. So I'm +1 for non-fix but
redefine the behavior. Who wants to limit the num
multi-phase
aggregate, but in theory the proposal above is state-merge function,
so it doesn't apply to general aggregate results that passed through
the final function. Of course some functions that don't have final
functions are ok to call state-merge function on the results.
Th
On Thu, Mar 29, 2012 at 12:51 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>> Frankly I'm still against this patch. Since I started to review it
>> I've never been convinced with the use case. Yeah, someone said it'd
>> be useful to him, but as a
and other patches, but
it seems to me that the quality of both of the design and patch code
are not adequate at this point of time. I think I agree we are not
100% happy with the current dependency system of extensions, but we
need more time to think and make it mature idea rather than rushing
and pushing and dropping something premature. The cost we would pay
if we rushed this to this release will be higher than what we'd get
from it, I think.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
input, we can continue the rest
of work.
Anyway the memory usage problem is not only array_agg and hash
aggregate. Even if you can say the hash table exceeds X% of the
work_mem, how can you tell other operators such like Sort are not
using the rest of memory? One approach I could see to avoid this is
whose name is the same as other base type. Is it intentional?
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Feb 24, 2012 at 2:09 PM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>> I confirmed DROP EXTENSION is fixed now. In turn, it seems to me
>> "requires" doesn't work. My test ext2.control looks like:
>
> I'm very sorry about that. It'
On Mon, Feb 13, 2012 at 3:18 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Sorry for the delays, I'm back on PostgreSQL related work again.
>
> Hitoshi Harada writes:
>>>> I just tried DROP EXTENSION now, and found it broken :(
>
> Please find v2 of the patch. I d
On Sat, Feb 11, 2012 at 11:34 AM, Jeff Janes wrote:
> On Wed, Feb 8, 2012 at 1:01 AM, Hitoshi Harada wrote:
>> On Sun, Jan 15, 2012 at 4:59 PM, Jeff Janes wrote:
>>>
>>> The attached patch allows it to reuse that memory. On my meager
>>> system it reduced th
t around the limitation. It shows a 2 fold
> improvement when indexing an integer column on a 50,000,000 row
> randomly ordered table.
In any case, we do need bird-eye sketch to attack it but I guess it's
worth and at some future point we definitely must do, though I don't
know if it
e 3 % gain by this change.
Correct me as I'm probably wrong.
Anyway, it's nice to modify the comment just above the change, since
it's now true with it.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 23, 2012 at 3:06 AM, Hitoshi Harada wrote:
> On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
> wrote:
>> Hitoshi Harada writes:
>>>>> - What happens if DROP EXTENSION ... CASCADE? Does it work?
>>>>
>>>> It should, what happens w
On Thu, Feb 2, 2012 at 3:19 PM, Tom Lane wrote:
> [ working on this patch now ... ]
>
> Matthew Draper writes:
>> On 25/01/12 18:37, Hitoshi Harada wrote:
>>> Should we throw an error in such ambiguity? Or did you make it happen
>>> intentionally? If latter, w
On Sun, Jan 29, 2012 at 1:08 AM, Matthew Draper wrote:
> On 25/01/12 18:37, Hitoshi Harada wrote:
>>> I'm still not sure whether to just revise (almost) all the SQL function
>>> examples to use parameter names, and declare them the "right" choice; as
>>
On Mon, Jan 23, 2012 at 7:13 PM, Matthew Draper wrote:
> On 19/01/12 20:28, Hitoshi Harada wrote:
>>> (Now it occurred to me that forgetting the #include parse_func.h might
>>> hit this breakage..., so I'll fix it here and continue to test, but if
>>> you'
On Thu, Jan 19, 2012 at 1:58 AM, Hitoshi Harada wrote:
> On Wed, Jan 18, 2012 at 1:11 AM, Hitoshi Harada wrote:
>> On Sat, Jan 14, 2012 at 8:10 AM, Matthew Draper wrote:
>>>
>>> I just remembered to make time to advance this from WIP to proposed
>>> patch
On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>>>> - What happens if DROP EXTENSION ... CASCADE? Does it work?
>>>
>>> It should, what happens when you try? :)
>>
>> I just tried DROP EXTENSION now, and found it
On Sat, Jan 21, 2012 at 9:20 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Thank you for reviewing this patch!
>
> Hitoshi Harada writes:
>> The patch applies with one reject, which I could fix easily. The make
>> check passed.
>
> Bitrot happens fast in this season… wi
I've reviewed quickly. I'll need more time to
look in detail, but I'd like more inputs for the high-level design and
direction.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
; before it ignored that work if log_checkpoints was off.
>
>
> ...and there's at least one I missed located already: inside of md.c. I'd
> forgotten how many spots where timing calls are optimized out are floating
> around this code path.
I think CF app page for this patch has missin
On Wed, Jan 18, 2012 at 1:11 AM, Hitoshi Harada wrote:
> On Sat, Jan 14, 2012 at 8:10 AM, Matthew Draper wrote:
>>
>> I just remembered to make time to advance this from WIP to proposed
>> patch this week... and then worked out I'm rudely dropping it into the
>
hit this breakage..., so I'll fix it here and continue to test, but if
you'll fix it yourself, let me know)
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 14, 2012 at 6:48 AM, Robert Haas wrote:
> On Sat, Jan 14, 2012 at 5:25 AM, Hitoshi Harada wrote:
>> The patch looks ok, though I wonder if we could have a way to release
>> the lock on namespace much before the end of transaction.
>
> Well, that wold kind of mis
On Sat, Jan 14, 2012 at 2:25 AM, Hitoshi Harada wrote:
> On Fri, Jan 13, 2012 at 2:05 PM, Robert Haas wrote:
>> On Tue, Nov 29, 2011 at 10:10 AM, Robert Haas wrote:
>>>
>>> I have plans to try to improve this, but it's one of those things that
>>> I care
rator family
- function (proc)
- ts_config
- ts_dict
- ts_parser
- ts_template
- (what's missing?)
I agree with you that it's not worth doing everything, but function is
nice to have. I don't mind if we don't have it with the other objects.
Thanks,
--
Hitoshi Harada
--
Sen
END AS what_about_case_expression
+
FROM generate_series(1, 100) a(a);
(1 row)
So my conclusion is it's better than nothing, but we could do better
job here. From timeline perspective, it'd be ok to apply this patch
and improve more later in 9.3+.
Thanks,
uild itself. Dunno how
they've changed since then.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ccount/login/?next=/account/ for sign up.
Now that you have uploaded it to PGXN, I hope many people will test it.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
filter. By that way, I guess
you can keep original information as well as filtered top-most target
list. Eventually you need to work on the planner, too. Though I've not
read all of the patch, the design rework should be done first. I'll
mark this as Waiting on Author.
Regards,
--
On Sat, Oct 29, 2011 at 8:13 AM, Tom Lane wrote:
> Hitoshi Harada writes:
>> I have a doubt here, on sharing connection for each server. What if
>> there are simultaneous scan on the same plan? Say,
>
>> -> Nested Loop
>> -> Foreign Scan to table T1 on serve
on's result (of T1) is discarded. Am I understand
correctly?
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ow specifications. Some
window functions like rank and row_number is meaningless if it is
omitted, so some implementation doesn't allow it omitted. And I
believe Oracle implemented it before the standard, so that'd be why
details are different from spec. We designed it per spec and omitting
the cl
2011/10/17 Tom Lane :
> Hitoshi Harada writes:
>> 2011/10/15 Tom Lane :
>>> I can't recall whether there was some good reason for underspecifying
>>> these test queries. It looks like all the problematic ones were added in
>>> commit ec4be2ee6827b6bd85
us to specify it. So +1 for adding the clauses.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tion that in chapter 5.10
> of the documentation?
Let's share it on PGXN! There are already three FDWs, and I'm gonig to
add one more.
Thanks,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rings = on. I didn't grep if there
other pages like this.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ding this paragraph, it might be
another work to make sublink expression look like the same as join.
But what we want to solve is the same goal, I think.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2011/7/27 Yeb Havinga :
> On 2011-07-22 17:35, Hitoshi Harada wrote:
>>
>> 2011/7/23 Yeb Havinga:
>
> A few days ago I read Tomas Vondra's blog post about dss tpc-h queries on
> PostgreSQL at
> http://fuzzy.cz/en/articles/dss-tpc-h-benchmark-with-postgresql/ - in w
2011/7/23 Yeb Havinga :
> On 2011-07-22 16:17, Hitoshi Harada wrote:
>>
>> :(
>> I updated the patch. Could you try attached once more? The "issafe"
>> switch seems wrong.
>
> Works like a charm :-). However, now there is always a copyObject of a
> s
2011/7/22 Yeb Havinga :
> On 2011-07-02 10:02, Hitoshi Harada wrote:
>>
>>> Although I still need to think about suitable regression test case,
>>> the patch itself can be reviewed again. You may want to try some
>>> additional tests as you imagine after f
2011/6/19 Hitoshi Harada :
> 2011/6/17 Andrew Tipton :
>>
>> At this point I'm a bit lost -- while pg_amop.h has plenty of examples
>> of crosstype comparison operators for btree index methods, there are
>> none for GiST. Is GiST somehow a special case in this re
2011/7/5 Hitoshi Harada :
> 2011/7/5 Yeb Havinga :
>> Hello Hitosh, list,
>>
>>> >
>>> > Attached is revised version.
>>>
>>> I failed to attached the patch. I'm trying again.
>>>
>> I'm currently unable to test,
my latest patch after he comes back. I'll make up my mind around
regression test.
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2011/7/2 Hitoshi Harada :
> 2011/6/29 Yeb Havinga :
>>
>> On 2011-06-17 09:54, Hitoshi Harada wrote:
>>>
>>> While reviewing the gist/box patch, I found some planner APIs that can
>>> replace parts in my patch. Also, comments in includes wasn't up
2011/6/29 Yeb Havinga :
>
> On 2011-06-17 09:54, Hitoshi Harada wrote:
>>
>> While reviewing the gist/box patch, I found some planner APIs that can
>> replace parts in my patch. Also, comments in includes wasn't updated
>> appropriately. Revised patch attached
2011/6/30 Yeb Havinga :
> On 2011-06-29 19:22, Hitoshi Harada wrote:
>>
>> Other things are all good points. Thanks for elaborate review!
>> More than anything, I'm going to fix the 6) issue, at least to find the
>> cause.
>>
> Some more questions:
>
developer can join to translate or fix the docs.
+1. If we really want to prove the demand, let's start with Wiki,
which is less invasive than README (though I doubt such pages would be
updated finally.)
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hack
2011/6/29 Yeb Havinga :
>
> On 2011-06-17 09:54, Hitoshi Harada wrote:
>>
>> While reviewing the gist/box patch, I found some planner APIs that can
>> replace parts in my patch. Also, comments in includes wasn't updated
>> appropriately. Revised patch attached.
&
2011/6/17 Andrew Tipton :
> On Fri, Jun 10, 2011 at 22:16, Hitoshi Harada wrote:
>>
>> Isn't it worth adding new consistent function for those purposes? The
>> approach in the patch as stands looks kludge to me.
>
> Thanks for your review. Coming back to this pat
2011/6/10 Hitoshi Harada :
> 2011/6/9 Robert Haas :
>> On Thu, Jun 9, 2011 at 2:28 AM, Hitoshi Harada wrote:
>>> BTW, as I changed title and design from the previous post, should I
>>> throw away the old commit fest entry and make the new one?
>>
>> Nah,
2011/6/17 Robert Haas :
> On Tue, Jun 14, 2011 at 11:18 PM, Hitoshi Harada wrote:
>> Yesterday on PGXN I just released the first version of planinstr, a
>> plugin module to append planner time to EXPLAIN. I post this here
>> since it is mostly for developers.
>
> Wow
ps://github.com/umitanuki/planinstr
Also free to fork and send pull request!
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 443 matches
Mail list logo