subxact;
UPDATE testcase SET balance = balance - 100 WHERE id=1;
ROLLBACK TO SAVEPOINT subxact;
-- "division by zero" shouldn't occur because I never deleted any rows
SELECT 1/count(*) from (
SELECT * FROM testcase WHERE id=1 FOR UPDATE
)x;
ROLLBACK;
Regards,
Marti Raudsepp
On Wed, Jun 11, 2014 at 11:53 AM, David Rowley wrote:
>> The only way to consistently guarantee nullability is through primary
>> key constraints. Fortunately that addresses most of the use cases of
>> NOT IN(), in my experience.
>> See the comment in check_functional_grouping:
> I saw that, but
On Sun, Jun 8, 2014 at 3:36 PM, David Rowley wrote:
> Currently pull_up_sublinks_qual_recurse only changes the plan for NOT EXISTS
> queries and leaves NOT IN alone. The reason for this is because the values
> returned by a subquery in the IN clause could have NULLs.
There's a bug in targetListIs
On Fri, Jun 13, 2014 at 12:46 PM, Dennis Butterstein wrote:
> I expect my current changes to be resposible for about 0.2-0.3s for this
> query but because of the huge time differences I am not able to quantify my
> changes.
>
> Maybe somebody can tell me about a better approach to quantify my chan
On Tue, Jun 17, 2014 at 5:23 PM, Dennis Butterstein wrote:
> I tried the proposed tweaks and
> see some differences regarding the measurements.
> Unfortunately the variance between the runs seems to remain high.
Using these techniques I managed to get standard deviation below 1.5%
in my read-only
On Wed, Jun 4, 2014 at 1:47 PM, Abhijit Menon-Sen wrote:
> Here's a patch to make pg_xlogdump print summary statistics instead of
> individual records.
Thanks! I had a use for this feature so I backported the (first) patch
to PostgreSQL 9.3. It's a rush job so it's ugly and may have bugs, but
it
On Tue, Jul 1, 2014 at 11:13 PM, Abhijit Menon-Sen wrote:
> In CF terms, did you form any opinion while porting the patch I posted
> about whether it's sensible/ready for inclusion in 9.5?
I didn't look at the code more than necessary to make the build work.
As far as functionality goes, it does
On Sat, Jul 5, 2014 at 5:38 PM, Kevin Grittner wrote:
> it seems to me that we need the full tuple to support triggers on
> FDWs, so the TID approach would be an optimization for a subset of
> the cases, and would probably be more appropriate, if we do it at
> all, in a follow-on patch
> If you di
On Mon, Jul 28, 2014 at 6:24 PM, Kevin Grittner wrote:
> Do you have some other suggestion? Keep in mind that it must allow
> the code which will *generate* the transition tables to know
> whether any of the attached triggers use a given transition table
> for the specific operation, regardless o
On Tue, Jul 29, 2014 at 9:49 AM, Pavel Stehule wrote:
> I dislike this proposal - it is strongly inconsistent with current trigger
> design
The real point I was trying to convey (in my previous email) is that
these declarations should be part of the trigger *function* not the
function-to-table re
On Thu, Jul 31, 2014 at 9:41 PM, Robert Haas wrote:
> I certainly like that better than poor-man; but proxy, to me, fails to
> convey inexactness.
Maybe "abbreviated", "abridged", "minified"?
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Mon, Aug 4, 2014 at 11:48 PM, testman1316 wrote:
> In both we ran code that did 1 million square roots (from 1 to 1 mill). Then
> did the same but within an If..Then statement.
> Note: once we started running queries on the exact same data in Oracle and
> PostgreSQL we saw a similar pattern. O
On Fri, Aug 8, 2014 at 10:50 PM, Hannu Krosing wrote:
> How hard and how expensive would it be to teach pg_lzcompress to
> apply a delta filter on suitable data ?
>
> So that instead of integers their deltas will be fed to the "real"
> compressor
Has anyone given this more thought? I know this mi
Hi
On Thu, May 8, 2014 at 4:28 PM, Andres Freund wrote:
> Ok. A new version of the patches implementing that are
> attached. Including a couple of small fixups and docs. The latter aren't
> extensive, but that doesn't seem to be warranted anyway.
Is it really actually useful to expose the segmen
On Mon, Jun 22, 2015 at 9:20 PM, Robert Haas wrote:
> On Fri, Jun 19, 2015 at 12:10 PM, Marti Raudsepp wrote:
>> One of my databases failed to upgrade successfully and produced this error
>> in the copying phase:
>>
>> error while copying relation "pg_catal
On Wed, Jul 22, 2015 at 5:00 PM, Robert Haas wrote:
> +1. I would recommend adding it to the CF *immediately* to have it
> get attention. The CF app is basically our patch tracker.
Thanks, I have done so now: https://commitfest.postgresql.org/6/313/
Regards,
Marti
--
Sent via pgsql-hackers
On Tue, Jan 14, 2014 at 5:06 AM, Dave Cole wrote:
> It would be really cool if you could direct the EXPLAIN ANALYZE output to a
> temporary table so that the query being analyzed could execute normally.
You can use the auto_explain contrib module to log the query plans of
slow(er) queries:
http:/
On Tue, Jan 14, 2014 at 5:13 AM, Marti Raudsepp wrote:
> You can use the auto_explain contrib module
I just remembered that there's also the pg_stat_plans extension, which
is closer to what you asked:
https://github.com/2ndQuadrant/pg_stat_plans . This one you'll have to
build yours
n the language without breaking backwards
compatibility.
On Tue, Jan 14, 2014 at 4:30 AM, Marko Tiikkaja wrote:
> On 2014-01-14 02:54, Marti Raudsepp wrote:
>> But PL/pgSQL already has an assignment syntax with the behavior you want:
>
> According to the docs, that doesn't s
On Tue, Jan 14, 2014 at 12:07 PM, knizhnik wrote:
> But is it possible to use index for derived table at all?
Yes, the planner will do an index scan when it makes sense.
> Why sequential search is used for derived table in the example below:
> insert into derived_table values (2,2);
> create in
On Tue, Jan 14, 2014 at 5:49 PM, Alexander Korotkov
wrote:
>> I implemented a new
>> enable_partialsort GUC to make it easier to turn on/off
> I though about such option. Generally not because of testing convenience,
> but because of overhead of planning. This way you implement it is quite
> naiv
On Tue, Jan 14, 2014 at 9:28 PM, Alexander Korotkov wrote:
> On Tue, Jan 14, 2014 at 11:16 PM, Marti Raudsepp wrote:
>
>> Oh, this actually highlights a performance regression with the partial
>> sort patch.
>>
>
> Interesting. Could you share the dataset?
>
On Wed, Jan 15, 2014 at 8:23 AM, Jim Nasby wrote:
> Do we actually support = right now? We already support
>
> v_field := field FROM table ... ;
>
> and I think it's a bad idea to have different meaning for = and :=.
That was already discussed before. Yes, we support both = and := and
they have e
Sort Key: a, i
Presorted Key: a
Sort Method: quicksort Memory: 27kB
-> Index Scan using longtext_a_idx on longtext (cost=0.65..1691.65
rows=1000 width=1160) (actual time=0.013..2.094 rows=1000 loops=1)
Total runtime: 5.418 ms
Regards,
Marti
From fbc6c31528018bca64dc54f65e1cd292f8de4
Funny, I just wrote a patch to do that some minutes ago (didn't see your
email yet).
http://www.postgresql.org/message-id/CABRT9RCK=wmFUYZdqU_+MOFW5PDevLxJmZ5B=etjjnubvya...@mail.gmail.com
Regards,
Marti
On Sat, Jan 18, 2014 at 7:10 PM, Jeremy Harris wrote:
> On 13/01/14 18:01, Alexander Kor
On Sat, Jan 18, 2014 at 7:22 PM, Marti Raudsepp wrote:
> Total runtime: 5.418 ms
Oops, shouldn't have rushed this. Clearly the timings should have
tipped me off that it's broken. I didn't notice that cmpSortSkipCols
was re-using tuplesort's sortkeys.
Here's a patch
Hi list,
It looks like the get_object_address_attribute() function has a
potential relcache leak. When missing_ok=true, the relation is found
but attribute is not, then the relation isn't closed, nor is it
returned to the caller.
I couldn't figure out any ways to trigger this, but it's best to fi
On Wed, Jan 15, 2014 at 5:34 AM, Jim Nasby wrote:
> it's very common to create temporary file data that will never, ever, ever
> actually NEED to hit disk. Where I work being able to tell the kernel to
> avoid flushing those files unless the kernel thinks it's got better things
> to do with that m
On Sun, Jan 19, 2014 at 8:10 PM, Tom Lane wrote:
> Complaining about a too-long varchar string in this style
> seems practically guaranteed to violate that.
Agreed. But I think it would be useful to add the length of the string
being inserted; we already have it in the len variable.
> One thing
2014/1/17 Jov
> but in the psql --help,-F say:
>
>> set field separator (default: "|")
> if user don't read the offical doc carefully,he can use:
>
>> psql -F , -c 'select ...'
>
> But can't get what he want.
> It is a bad user Experience.
+1 from me, patch applies and is helpful.
After patchin
On Tue, Nov 19, 2013 at 6:38 PM, Andres Freund wrote:
> The attached patches compile and make check successfully on linux x86,
> amd64 and msvc x86 and amd64. This time and updated configure is
> included. The majority of operations still rely on CAS emulation.
Note that the atomics-generic-acc.h
On Mon, Jan 20, 2014 at 1:51 AM, Dave Chinner wrote:
>> Postgres is far from being the only application that wants this; many
>> people resort to tmpfs because of this:
>> https://lwn.net/Articles/499410/
>
> Yes, we covered the possibility of using tmpfs much earlier in the
> thread, and came to
Hi,
On Tue, Jan 14, 2014 at 5:49 PM, Alexander Korotkov
wrote:
>On Tue, Jan 14, 2014 at 12:54 AM, Marti Raudsepp wrote:
>> I've been trying it out in a few situations. I implemented a new
>> enable_partialsort GUC to make it easier to turn on/off, this way it's a l
On Mon, Jan 20, 2014 at 2:04 PM, Jov wrote:
> reasonable，I removed the "set",patch attached.
Hi Jov,
A new commitfest was just opened, due on 2014-06. Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view?id=22
(You'll need a community account if you don't already
On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata wrote:
> Here is the patch to implement to_regclass, to_regproc, to_regoper,
> and to_regtype.
+ static Datum regclass_guts(char *class_name_or_oid, bool raiseError);
Minor bikeshedding, a lot of code currently uses an argument named
"missing_ok" for
On Wed, Jan 22, 2014 at 1:44 PM, Yugo Nagata wrote:
> On Wed, 22 Jan 2014 20:04:12 +0900 (JST)
> Tatsuo Ishii wrote:
> parseTypeString() is called by some other functions and I avoided
> influences of modifying the definition on them, since this should
> raise errors in most cases. This is same r
On Mon, Jan 20, 2014 at 2:43 PM, Alexander Korotkov
wrote:
> Another changes in this version of patch:
> 1) Applied patch to don't compare skipCols in tuplesort by Marti Raudsepp
> 2) Adjusting sort bound after processing buckets.
Hi,
Here's a patch with some whitespace and
On Sun, Jan 26, 2014 at 11:19 AM, Simon Riggs wrote:
> For 9.4, we should cut down the patch so it has
> plpgsql.warnings = none (default) | all | [individual item list]
> plpgsql.warnings_as_errors = off (default) | on
I hope I'm not late for the bikeshedding :)
Why not have 2 similar opti
On Mon, Jan 27, 2014 at 9:26 PM, Alexander Korotkov
wrote:
> For now, I have attempt to fix extra columns in mergejoin problem. It would
> be nice if you test it.
Yes, it solves the test cases I was trying with, thanks.
> 1) With enable_partialsort = off all mergejoin logic should behave as
> wi
On Tue, Jan 28, 2014 at 7:51 AM, Alexander Korotkov
wrote:
> I didn't test it, but I worry that overhead might be high.
> If it's true then it could be like constraint_exclusion option which id off
> by default because of planning overhead.
I see, that makes sense.
I will try to find the time to
On Tue, Jan 28, 2014 at 7:51 AM, Alexander Korotkov wrote:
> On Tue, Jan 28, 2014 at 7:41 AM, Marti Raudsepp wrote:
>
>> But some benchmarks of planning performance are certainly warranted.
>>
>
> I didn't test it, but I worry that overhead might be high.
> If
On Thu, Feb 6, 2014 at 5:31 AM, Robert Haas wrote:
> Hmm, sounds a little steep. Why is it so expensive? I'm probably
> missing something here, because I would have thought that planner
> support for partial sorts would consist mostly of considering the same
> sorts we consider today, but with t
On Tue, Jan 28, 2014 at 10:38 AM, Yugo Nagata wrote:
> I revised the patch. Could you please review this?
I didn't test the patch due to the duplicate OID compilation error.
But a few things stuck out from the diffs:
* You added some unnecessary spaces at the beginning of the linein
OpernameGetCa
On Thu, Feb 6, 2014 at 9:15 PM, Robert Haas wrote:
> It may be that having the capability to do a
> partial sort makes it seem worth spending more CPU looking for merge
> joins, but I'd vote for making any such change a separate patch.
Agreed.
Alexander, should I work on splitting up the patch i
On Sun, Feb 9, 2014 at 7:37 PM, Alexander Korotkov wrote:
> This is not only place that worry me about planning overhead. See
> get_cheapest_fractional_path_for_pathkeys. I had to estimate number of
> groups for each sorting column in order to get right fractional path.
AFAICT this only happens o
y not a fluke, however; it happens every time.
> On Mon, Feb 10, 2014 at 2:33 PM, Marti Raudsepp wrote:
>> AFAICT this only happens once per plan and the overhead is O(n) to the
>> number of pathkeys?
I was of course wrong about that, it also adds extra overhead when
iterating ove
On Sun, Feb 16, 2014 at 10:41 PM, Tom Lane wrote:
> Any comments before I start transposing them into the back branches?
Sorry I'm late.
> Shore up GRANT ... WITH ADMIN OPTION restrictions (Noah Misch)
I'm not familiar with the phrase "Shore up", I think it should use
more precise language: are
On Wed, Feb 12, 2014 at 11:54 PM, Marti Raudsepp wrote:
> With partial-sort-basic-1 and this fix on the same test suite, the
> planner overhead is now a more manageable 0.5% to 1.3%; one test is
> faster by 0.5%.
Ping, Robert or anyone, does this overhead seem bearable or is that
still
On Thu, Feb 20, 2014 at 12:07 PM, Ashutosh Bapat
wrote:
> That seems a good idea. We will get rid of FETCH_COUNT then, wouldn't we?
No, I don't think we want to do that. FETCH_COUNT values greater than
1 are still useful to get reasonably tabulated output without hogging
too much memory. For exam
On Thu, Jan 16, 2014 at 5:22 PM, Tom Lane wrote:
> but adding
> volatility here seems like probably a waste of valuable terminal width.
> I think that the vast majority of operators have immutable or at worst
> stable underlying functions, so this doesn't seem like the first bit
> of information I
On Tue, May 14, 2013 at 4:12 AM, Marti Raudsepp wrote:
> While testing out PostgreSQL 9.3beta1, I stumbled upon a problem
> % make DESTDIR=/tmp/foo install
> /usr/bin/install: will not overwrite just-created
> ‘/tmp/foo/usr/share/postgresql/extension/semver--0.3.0.sql’ with
>
On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain
wrote:
> Marti Raudsepp a écrit :
>>Did we ever do anything about this? It looks like the thread got
>>distracted with VPATH builds and now I'm seeing this problem in 9.3.0.
> Andrew is about to commit (well...I hope) a d
On Tue, Sep 17, 2013 at 10:37 AM, Cédric Villemain
wrote:
>> Erm, isn't apt.postgresql.org supposed to ship the *official*
>> PostgreSQL versions? Given that this issue affects all distros, I
>> don't see why Ubuntu/Debian need to be patched separately.
> Well, the patches are applyed on the debi
On Fri, Sep 13, 2013 at 8:17 PM, Marti Raudsepp wrote:
> On Fri, Sep 13, 2013 at 6:42 PM, Cédric Villemain
> wrote:
>> Andrew is about to commit (well...I hope) a doc patch about that and also a
>> little fix.
>> Imho this is a bugfix so I hope it will be applyed in
Hi Andrew,
On Mon, Sep 23, 2013 at 6:43 PM, Andrew Dunstan wrote:
> I'm working on it. It appears to have a slight problem or two I want to fix
> at the same time, rather than backpatch something broken.
Any progress on this? I notice that the fixes didn't make it into 9.3.1.
Regards,
Marti
-
On Wed, Sep 23, 2015 at 3:01 AM, Peter Geoghegan wrote:
> I think that the real problem here is that garbage collection needs to
> deal with OOM more appropriately.
+1
I've also been seeing lots of log messages saying "LOG: out of
memory" on a server that's hosting development databases. I put
Hi list
The attached patch changes the behavior of multiple ALTER x SET SCHEMA
commands, to skip, rather than fail, when the old and new schema is
the same.
The advantage is that it's now easier to write DDL scripts that are indempotent.
This already matches the behavior of ALTER EXTENSION SET S
Hi Gavin
Note that Alexander Korotkov already started work in 2013 on a
somewhat similar feature called partial sort:
http://www.postgresql.org/message-id/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=gon-...@mail.gmail.com
In particular, see the 2nd patch for KNN sort -- it uses known
bounding box
On Wed, Feb 1, 2012 at 20:17, Tom Lane wrote:
> Applied with minor revisions.
Thanks! :)
We're already seeing first buildfarm failures, on system "narwhal"
using an msys/mingw compiler.
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhal&dt=2012-02-02%2005%3A00%3A02
No idea which libc it
On Mon, Jan 30, 2012 at 20:33, Gilles Darold wrote:
> After some time searching for a Pg system administration function like
> pg_is_in_recovery(), let's say pg_is_in_backup(), I couldn't find one.
> The minor patch attached here adds this administrative function that can
> be used with others bac
On Sat, Feb 4, 2012 at 09:49, Jaime Casanova wrote:
> i little review...
Thanks! By the way, you should update to the v7 patch.
> first, i notice a change of behaviour... i'm not sure if i can say
> this is good or not.
> if you execute: select *, cached_random() from (select
> generate_series(
Hi list,
Andrew Dunstan reported an awkward-seeming case on IRC where shifting
around a concatenation expression in a view made the planner choose a
good or a bad execution plan.
Simplified, it boils down to this:
db=# create table foo(i int);
db=# explain verbose select i from (select i, i::tex
On Tue, Feb 7, 2012 at 22:31, Andrew Dunstan wrote:
> It gets worse if you replace the expression with a call to a (non-sql)
> function returning text, which was in fact the original use case. Then
> you're pretty much hosed.
Oh, if it's a non-SQL function then marking it as STABLE/IMMUTABLE
sho
On Wed, Feb 8, 2012 at 06:21, Tom Lane wrote:
> Marti Raudsepp writes:
>> Case #1 uses the normal textcat(text, text) operator by automatically
>> coercing 'x' as text.
>> However, case #2 uses the anytextcat(anynonarray, text), which is
>> marked as volatile
On Wed, Feb 8, 2012 at 18:20, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp wrote:
>>> Patch attached (in git am format). Passes all regression tests (except
>>> 'json' which fails on my machine even on git master)
On Wed, Feb 8, 2012 at 19:48, Tom Lane wrote:
> I applied this patch, since I was busy applying catalog changes from you
> anyway ;-).
Thanks :)
> I did think of a possible reason to reject the patch: with this change,
> the planner will take longer to plan queries involving bool_and() et al,
>
Hi!
I've always been a little wary of using the TRUNCATE command due to
the warning in the documentation about it not being "MVCC-safe":
queries may silently give wrong results and it's hard to tell when
they are affected.
That got me thinking, why can't we handle this like a standby server
does
On Sat, Feb 11, 2012 at 01:54, Gaetano Mendola wrote:
> I wonder if somewhere in Postgres source "we" are relying on the GCC
> "correct behaviour" regarding the read-modify-write of bitfield in
> structures.
Probably not. I'm pretty sure that we don't have any bitfields, since
not all compilers a
On Mon, Feb 13, 2012 at 15:08, Robert Haas wrote:
> Honestly, I think the biggest hassle of the OID code is not so much
> the way they're generated as the way they're stored within heap
> tuples. I've wondered whether we should go through the system
> catalogs and replace all of the hidden OID co
On Mon, Feb 13, 2012 at 20:48, Greg Stark wrote:
> I don't think we should be looking at either CUDA or OpenCL directly.
> We should be looking for a generic library that can target either and
> is well maintained and actively developed.
I understand your point about using some external library f
On Thu, Feb 16, 2012 at 19:18, Dan Scales wrote:
> fsync/fdatasync can be very slow on ext3, because it seems to have to
> always wait for the current filesystem meta-data transaction to complete,
> even if that meta-data operation is completely unrelated to the file
> being fsync'ed.
Use the dat
On Fri, Feb 17, 2012 at 17:42, Jay Levitt wrote:
> Should it be something like
>
> Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group
> Portions Copyright (c) 2012, TipTap Inc.
Please don't add that, just change 2011 to 2012. This is what the wiki says:
Q: May I add my own cop
On Wed, Feb 22, 2012 at 18:44, Greg Smith wrote:
> As far as I've been able to tell, there aren't any issues unique to Windows
> there. Multiple cores can have their TSC results get out of sync on Windows
> for the same reason they do on Linux systems, and there's also the same
> frequency/temper
On Wed, Feb 22, 2012 at 19:36, Greg Smith wrote:
> From the patch:
>
> Newer operating systems may check for the known TSC problems and
> switch to a slower, more stable clock source when they are seen.
> If your system supports TSC time but doesn't default to that, it
> may be disabled for a good
Hi,
Here's a tiny cleanup: currently get_tables_to_cluster uses
heap_open() to open the relation, but then closes it with
relation_close(). Currently relation_close=heap_close, but it seems
like good idea to be consistent -- in case these functions need to
diverge in the future.
Regards,
Marti
d
On Sat, Mar 3, 2012 at 14:53, Simon Riggs wrote:
> Thanks Noah for drawing attention to this thread. I hadn't been
> watching. As you say, this work would allow me to freeze rows at load
> time and avoid the overhead of hint bit setting, which avoids
> performance issues from hint bit setting in c
Hi,
I'm trying to write my first PostgreSQL C extension. I used the
pgxn-utils skeleton as a base and specified some external libraries in
SHLIB_LINK. However, this variable was ignored when linking the
library (using pgxs from current git master).
After spending quite a bit of time trying to und
Hi list,
This patch enables a simple optimization in
eval_const_expressions_mutator. If we know that one argument to
DistinctExpr is NULL then we can optimize it to a NullTest, which can
be an indexable expression.
For example the query:
EXPLAIN (costs off) SELECT * FROM foo WHERE j IS NOT DISTIN
On Thu, Mar 8, 2012 at 19:35, Tom Lane wrote:
> Uh ... how much do we care about that? I can't say that I've heard many
> people complain about the fact that IS [NOT] DISTINCT FROM is poorly
> optimized -- which it is, in general, and this patch chips away at that
> only a tiny bit, not enough to
On Sat, Mar 10, 2012 at 02:05, Tom Lane wrote:
> Marti Raudsepp writes:
>> [ cacheexpr-v8.patch ]
>
> A few comments
Whoa, that's quite a few. Thanks for the review.
> * There's a lot of stuff that seems wrong in detail in
> eval_const_expressions_mutator, eg it
Hi list,
Per Tom's request, I split out this refactoring from my CacheExpr patch.
Basically I'm just centralizing the eval_const_expressions_mutator()
call on function arguments, from multiple different places to a single
location. Without this, it would be a lot harder to implement argument
cach
Hi list,
I don't know who's maintaining the PostgreSQL GitHub mirror, but it
hasn't been updated for 6 days now:
https://github.com/postgres/postgres
Just letting you know.
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Sat, Mar 24, 2012 at 01:17, Tom Lane wrote:
> I've applied a slightly-modified version of this after reconciling it
> with the protransform fixes.
Cool, thanks!
> I assume you are going to submit a rebased
> version of the main CacheExpr patch?
Yeah, I'm still working on addressing the comme
Hi,
> On 07/29/2013 01:05 AM, Tom Lane wrote:
>> Buildfarm member anchovy has been failing for the last couple of days,
>> evidently because its owner just couldn't wait to adopt bison 3.0,
>> which is all of 3 days old.
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
On Mon, Jul 29, 2013 at 5:53 PM, Andres Freund wrote:
> Both the
> gcc 4.8 and the bison 3.0 problems are things the project needs to know
> about
Perl 5.18 too:
http://www.postgresql.org/message-id/2825.1370226...@sss.pgh.pa.us
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Mon, Jul 29, 2013 at 9:15 PM, Andrew Dunstan wrote:
> There has to be something between "set in stone and never changes" and
> "auto-updates everything every 24 hours" that would suit us.
Well sure I could change the update frequency. But again, it seems
like delaying the inevitable.
> I'm to
On Tue, Jul 30, 2013 at 3:56 AM, Noah Misch wrote:
> Agreed. Let's stick an "Updates OS packages daily, regularly acquiring
> bleeding-edge upstream releases" note on the buildfarm status page
FWIW, I added "[updated daily]" to the OS version field.
I haven't changed other configuration yet, wi
On Thu, Aug 28, 2014 at 12:03 AM, Kevin Grittner wrote:
>> In essence, make the relations work like PL/pgSQL
>> variables do. If you squint a little, the new/old relation is a variable
>> from the function's point of view, and a parameter from the
>> planner/executor's point of view. It's just a v
On Mon, Sep 1, 2014 at 9:09 PM, Tom Lane wrote:
> OTOH, I agree with Kevin that the things we're talking about are
> lightweight relations not variables.
My worry is that PL/pgSQL and Postgres's SQL dialect is turning into a
Frankenstein monster with many ways to do the same thing, each having
di
On Wed, Sep 3, 2014 at 10:49 PM, Kevin Grittner wrote:
> Marti Raudsepp wrote:
>> The concept of "lightweight relations" that pop into existence when a
>> certain kind of trigger definition is used somewhere in the function
>> stack, without a CREATE TABLE
On Wed, Sep 17, 2014 at 2:00 PM, David Rowley wrote:
> Anyway... I've been thinking of writing some code that converts these sub
> plans into left joins where it can be proved that the subquery would only at
> most produce 1 row
> Does anyone have any thoughts on this?
+1, I've thought about thi
On Fri, Sep 12, 2014 at 9:41 PM, Andrew Gierth
wrote:
> gsp1.patch - phase 1 code patch (full syntax, limited functionality)
> gsp2.patch - phase 2 code patch (adds full functionality using the
> new chained aggregate mechanism)
I gave these a try by convertin
On Fri, Sep 19, 2014 at 4:45 AM, Andrew Gierth
wrote:
> GroupAggregate (cost=1122.39..1197.48 rows=9 width=8)
>Group Key: two, four
>Group Key: two
>Group Key: ()
> "Grouping Sets": [
> ["two", "four"],
> ["two"],
> []
+1 looks good to me.
> (yaml for
f the
whole subquery.
Regards,
Marti
From 3448408121e7e32a12fc16403c9d48bce63503f5 Mon Sep 17 00:00:00 2001
From: Marti Raudsepp
Date: Wed, 1 Oct 2014 02:17:21 +0300
Subject: [PATCH] Simplify EXISTS subqueries containing LIMIT
---
src/backend/optimizer/plan/subselect.c | 40 +++
On Wed, Oct 1, 2014 at 2:42 PM, Fabrízio de Royes Mello
wrote:
> So, what's the correct/best grammar?
> CREATE [ IF NOT EXISTS ] [ UNIQUE ] INDEX index_name
> or
> CREATE [ UNIQUE ] INDEX [ IF NOT EXISTS ] index_name
I've elected myself as the reviewer for this patch. Here are some
preliminary co
On Tue, Aug 26, 2014 at 4:20 PM, Heikki Linnakangas
wrote:
> On 04/14/2014 10:31 PM, Fabrízio de Royes Mello wrote:
>> The attached patch contains CINE for sequences.
>>
>> I just strip this code from the patch rejected before.
>
> Committed with minor changes
Hmm, the CommitFest app lists Marko
On Fri, Oct 3, 2014 at 2:15 AM, Marti Raudsepp wrote:
> + ereport(NOTICE,
> + (errcode(ERRCODE_DUPLICATE_TABLE),
> + errmsg("relation \"%s\" already exists, skipping",
> + indexRelationName)));
>
"On Fri, Oct 3, 2014 at 6:25 AM, Fabrízio de Royes Mello
wrote:
>> Documentation: I would prefer if the explanation were consistent with
> "Do not throw an error if the index already exists. A notice is issued in
> this case."
> Fixed in that way. Ok?
And also "Note that there is no guarantee th
On Fri, Oct 3, 2014 at 7:25 PM, Fabrízio de Royes Mello
wrote:
> I agree with your grammar change.
Cool.
> The version 5 (attached) contains all discussed until now.
From documentation:
CREATE INDEX ... [ IF NOT EXISTS name | name ] ON ...
Maybe I'm just slow, but it took me a few minutes to
On Mon, Oct 6, 2014 at 4:17 AM, Fabrízio de Royes Mello
wrote:
> On Sun, Oct 5, 2014 at 9:52 AM, Marti Raudsepp wrote:
>> CREATE INDEX ... [ IF NOT EXISTS name | name ] ON ...
>>
>> Maybe I'm just slow, but it took me a few minutes to understand what
>> this m
1 - 100 of 285 matches
Mail list logo
