On 20 November 2011 03:29, Peter Geoghegan wrote:
> ./configure CFLAGS="-fno-inline -fno-inline-small-functions" (I could
> have disabled more -02 optimisations, but this proved sufficient to
> make my point)
I'll isolate this further to tuplesort.c soon, which ought to be a lot
more useful.
--
On 19 November 2011 02:55, Robert Haas wrote:
> Maybe we should look at trying to isolate that a bit better.
Indeed. Fortunately, GCC has options to disable each optimisation.
Here's potentially relevant flags that we're already implicitly using
at -02:
-finline-small-functions <-- this is the o
On Nov19, 2011, at 21:57 , Tom Lane wrote:
> One thing I've been thinking for a bit is that for discrete ranges,
> I find the '[)' canonical form to be surprising/confusing. If we
> were to fix range_adjacent along the lines suggested by Florian,
> would it be practical to go over to '[]' as the c
On Nov19, 2011, at 22:03 , Tom Lane wrote:
> Jeff Davis writes:
>> On Fri, 2011-11-18 at 14:47 -0500, Tom Lane wrote:
>>> Yeah, probably not. However, I don't like the idea of
>>> '(3,4)'::int4range throwing an error, as it currently does, because it
>>> seems to require the application to have q
Hi,
2011-11-17 14:53 keltezéssel, Michael Meskes írta:
> On Mon, Nov 14, 2011 at 09:06:30AM +0100, Boszormenyi Zoltan wrote:
>> Yes, you are right. For timestamp and interval, the safe alignment is int64.
>> Patch is attached.
> Applied, thanks.
>
> Michael
thanks.
Hopefully last turn in this to
Jeff Davis writes:
> On Fri, 2011-11-18 at 14:47 -0500, Tom Lane wrote:
>> Yeah, probably not. However, I don't like the idea of
>> '(3,4)'::int4range throwing an error, as it currently does, because it
>> seems to require the application to have quite a lot of knowledge of the
>> range semantics
Jeff Davis writes:
> On Sat, 2011-11-19 at 12:27 -0500, Tom Lane wrote:
>> I don't immediately see a solution that's better than dropping the
>> single-argument range constructors.
> We could change the name, I suppose, but that seems awkward.
Yeah, something like int4range_1(42) would work, but
2011/11/19 Jeff Davis :
> On Sat, 2011-11-19 at 12:27 -0500, Tom Lane wrote:
>> The singleton range constructors don't work terribly well.
> ...
>
>> I don't immediately see a solution that's better than dropping the
>> single-argument range constructors.
>
> We could change the name, I suppose, bu
Thanks for your reviewing.
The reason of this strange message was bug is the patch.
> CREATE TABLE public.copy1(a, b) AS SELECT * FROM public.test;
> ERROR: whole-row update is not implemented
When it constructs a fake RangeTblEntry, it marked modifiedCols for
attribute 0 to (tupdesc->natts - 1
On Sat, 2011-11-19 at 12:27 -0500, Tom Lane wrote:
> The singleton range constructors don't work terribly well.
...
> I don't immediately see a solution that's better than dropping the
> single-argument range constructors.
We could change the name, I suppose, but that seems awkward. I'm
hesitant
On Fri, 2011-11-18 at 14:47 -0500, Tom Lane wrote:
> Yeah, probably not. However, I don't like the idea of
> '(3,4)'::int4range throwing an error, as it currently does, because it
> seems to require the application to have quite a lot of knowledge of the
> range semantics to avoid having errors sp
2011/11/18 Robert Haas :
> On Tue, Nov 15, 2011 at 4:43 AM, Kohei KaiGai wrote:
>> Part-2) Groundworks on objectaddress.c
>> This patch adds necessary groundworks for Part-3 and Part-4.
>> It adds ObjectPropertyType of objectaddress.c index-oid and cache-id
>> for name lookup and attribute number
Hanada-san,
I'm still under reviewing of your patch, so the comment is not overall, sorry.
I'm not sure whether the logic of is_foreign_expr() is appropriate.
It checks oid of the function within FuncExpr and OpExpr to disallow to push
down user-defined functions.
However, if a user-defined opera
Andres Freund writes:
> On Saturday, November 19, 2011 04:52:10 PM Tom Lane wrote:
>> If you don't like CREATE RULE, try having your test program send just
>> Parse messages, and not Bind/Execute.
> That sounds like a plan. Except that I would prefer to use pgbench.
Well, how about plan C: writ
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Now, if you could do something that *doesn't* restrict what operations
> could be applied to the lists, that would be good.
If the API is followed, I believe my previous patch works for
everything, but it wasn't variable about the size of the new list.
Perh
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> For that I added new functions/defines which allocate all the needed memory
> in
> one hunk:
> list_immutable_make$n(),
> List *list_new_immutable_n(NodeTag t, size_t n);
> List *list_make_n(NodeTag t, size_t n, ...);
A while back, I posted
The singleton range constructors don't work terribly well.
regression=# select int4range(42); -- ok
int4range
---
[42,43)
(1 row)
regression=# select int4range(null);-- not so ok
int4range
---
(1 row)
regression=# select int4range('42');
On Saturday, November 19, 2011 04:52:10 PM Tom Lane wrote:
> Andres Freund writes:
> > Explain is just a vehicle here, I admit that. But on what else should I
> > bolt it?
>
> If you don't like CREATE RULE, try having your test program send just
> Parse messages, and not Bind/Execute.
That sound
On 11/18/2011 09:35 AM, Tom Lane wrote:
Subdividing/rearranging contrib makes the packager's
life more complicated, *and* makes his users' lives more complicated,
if only because things aren't where they were before. It seems unlikely
to happen, at least in the near term.
Users are visibly
On 19 November 2011 16:08, Tom Lane wrote:
> Thom Brown writes:
>> So is there a chance of getting bitmap index-only scans?
>
> Don't hold your breath. It seems like a huge increment of complexity
> for probably very marginal gains. The point of a bitmap scan (as
> opposed to regular indexscan)
Thom Brown writes:
> So is there a chance of getting bitmap index-only scans?
Don't hold your breath. It seems like a huge increment of complexity
for probably very marginal gains. The point of a bitmap scan (as
opposed to regular indexscan) is to reduce heap accesses by combining
visits to the
Andres Freund writes:
> Explain is just a vehicle here, I admit that. But on what else should I bolt
> it?
If you don't like CREATE RULE, try having your test program send just
Parse messages, and not Bind/Execute. I still dislike the idea of
exposing a fundamentally-broken-and-useless variant
Simon Riggs writes:
> On Thu, Nov 3, 2011 at 6:12 PM, Alvaro Herrera
> wrote:
>> So Noah Misch proposed using the FOR KEY SHARE syntax, and that's what I
>> have implemented here. (There was some discussion that instead of
>> inventing new SQL syntax we could pass the necessary lock mode
>> int
On 11/18/2011 03:36 PM, Josh Berkus wrote:
Of course, packagers may then reasonably ask why that code is not just
part of the core?
Let me step back from the implementation ideas for a minute and talk
about this, and how it ties into release philosophy. The extensions
infrastructure for
On Thu, Nov 3, 2011 at 6:12 PM, Alvaro Herrera wrote:
> So Noah Misch proposed using the FOR KEY SHARE syntax, and that's what I
> have implemented here. (There was some discussion that instead of
> inventing new SQL syntax we could pass the necessary lock mode
> internally in the ri_triggers co
On Thu, Nov 10, 2011 at 8:17 PM, Christopher Browne wrote:
> On Sun, Nov 6, 2011 at 2:28 AM, Jeroen Vermeulen wrote:
>> On 2011-11-04 01:12, Alvaro Herrera wrote:
>>
>>> I would like some opinions on the ideas on this patch, and on the patch
>>> itself. If someone wants more discussion on implem
26 matches
Mail list logo
