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
ote:
> > On Tue, Sep 29, 2015 at 12:17 AM, Marti Raudsepp
> wrote:
> >> 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 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
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
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
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 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
ged without recreating the DB, but
those don't matter for the pg_upgrade case anyway.
It seems those would be good material for another patch?
Regards,
Marti Raudsepp
0001-Fix-pg_upgrade-when-postgres-template1-aren-t-in-def.patch
Description: binary/octet-stream
--
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, Oct 24, 2014 at 11:29 AM, Kyotaro HORIGUCHI
wrote:
> - 0001-ALTER-ROLE-CURRENT_USER_v2.patch - the patch.
+RoleId:CURRENT_USER{ $$ = "current_user";}
+ | USER { $$ = "current_user";}
+ | CURRENT_ROL
a planner-only change so it makes sense to test EXPLAIN output.
The dilemma I always have is: wouldn't this cause failures due to plan
instability, if for example autoanalyze gets around to this table
earlier or later and nudges it from a hash join to merge etc? Or is
this not a problem?
Patch at
Hi
On Wed, Oct 22, 2014 at 1:55 PM, Teodor Sigaev wrote:
> With patch it's possible to rewrite query with ranges
> SELECT * FROM test_int4 WHERE i <@ '[-1, 1]'::int4range
> and GIN index will support this query with single scan from -1 to 1.
Shouldn't this be implemented in a more generic manner
Hi
Thanks for taking a look.
On Sun, Oct 19, 2014 at 1:22 PM, David Rowley wrote:
> the argument for this would
> have been much stronger if anti join support had just been added last week.
> It's been quite a few years now and the argument for this must be getting
> weaker with every release.
On Tue, Oct 21, 2014 at 3:53 AM, Wim Lewis wrote:
> I think the idea of OnDemand is for launchd items to act a bit like inetd
> does: launchd creates the listening socket (or mach port or file-change
> notification) on the port specified in the plist, and only starts the
> process when someone tri
On Oct 17, 2014 6:16 PM, "Tom Lane" wrote:
> A more realistic objection goes like this:
>
> create table foo(f int, g int);
> update foo x set x = (1,2); -- works
> alter table foo add column x int;
> update foo x set x = (1,2,3); -- no longer works
>
> It's not a real good thing if a column add
Hi
On Wed, Oct 15, 2014 at 11:02 AM, Atri Sharma wrote:
> Please find attached a patch which implements support for UPDATE table1
> SET(*)=...
I presume you haven't read Tom Lane's proposal and discussion about
multiple column assignment in UPDATE:
http://www.postgresql.org/message-id/1783.13990
Hi list,
I happened to notice that there are no less than 14 places in the code
that check whether a relation is a system catalog and throwing the
error "permission denied: "foo" is a system catalog"
The attached patch factors all of those into a single
ForbidSystemTableMods() function. Is this c
On Thu, Oct 2, 2014 at 4:21 PM, Michael Banck wrote:
> we have seen repeatedly that users can be confused about why PostgreSQL
> is not shutting down even though they requested it. Usually, this is
> because `log_checkpoints' is not enabled and the final checkpoint is
> being written, delaying sh
On Thu, Oct 9, 2014 at 11:11 AM, Peter Geoghegan wrote:
> On Thu, Oct 9, 2014 at 12:38 AM, Simon Riggs wrote:
>> Do not use CONFLICTING() which looks like it is a function.
>
> So is ROW(). Or COALESCE().
ROW and COALESCE behave almost like functions: they operate on any
expression or value you
On Thu, Oct 9, 2014 at 4:56 AM, Marti Raudsepp wrote:
> create trigger ev1 before insert on evt_type execute procedure ins();
> create trigger ev2 before update on evt_type execute procedure upd();
> create trigger ev3 after insert on evt_type execute procedure ins();
> create trigg
On Thu, Oct 9, 2014 at 4:25 AM, Peter Geoghegan wrote:
> On Wed, Oct 8, 2014 at 6:12 PM, Marti Raudsepp wrote:
>> Skipping
>> BEFORE UPDATE entirely seems to violate POLA.
> Good thing that the patch doesn't do that, then. I clearly documented
> this in a few
On Thu, Oct 9, 2014 at 3:47 AM, Peter Geoghegan wrote:
> On Wed, Oct 8, 2014 at 5:37 PM, Marti Raudsepp wrote:
>> Only in case the trigger changes *key* columns necessary for atomicity
>> (i.e. from the WITHIN index). Other columns are fair game. The
>> restriction seems ju
On Thu, Oct 9, 2014 at 2:46 AM, Peter Geoghegan wrote:
>> Indeed, the current behavior breaks even the canonical "keep track of
>> how many posts are in a thread" trigger example
> use an AFTER trigger for this kind of thing, and all of these
> issues go away.
In the latest patches from CommitFes
On Thu, Oct 9, 2014 at 1:51 AM, Peter Geoghegan wrote:
> On Wed, Oct 8, 2014 at 2:01 PM, Kevin Grittner wrote:
>> Although the last go-around does suggest that there is at least one
>> point of difference on the semantics. You seem to want to fire the
>> BEFORE INSERT triggers before determining
On Thu, Sep 4, 2014 at 12:14 AM, Kevin Grittner wrote:
>> Did I miss something?
>
> Apparently. I did a search on the document and counted and got 101
> occurrences of "transition table".
> | A transient table is a named table that may come into existence
> | implicitly during the evaluation of a
On Wed, Oct 8, 2014 at 12:28 PM, Peter Geoghegan wrote:
> On Wed, Oct 8, 2014 at 1:36 AM, Marti Raudsepp wrote:
>> I think there's a subtle difference in expectations too. The current
>> BEFORE INSERT trigger behavior is somewhat defensible with an
>> INSERT-driven synt
On Tue, Oct 7, 2014 at 2:27 PM, Marti Raudsepp wrote:
> but the new approach seems
> surprising: changes from BEFORE INSERT get persisted in the database,
> but AFTER INSERT is not fired.
I am sorry, I realize now that I misunderstood the current proposed
trigger behavior, I thought w
On Wed, Oct 8, 2014 at 3:47 AM, Peter Geoghegan wrote:
> It seems like what you're talking about here is just changing the
> spelling of what I already have.
I think there's a subtle difference in expectations too. The current
BEFORE INSERT trigger behavior is somewhat defensible with an
INSERT-d
On Thu, Sep 4, 2014 at 12:13 AM, Peter Geoghegan wrote:
> On Wed, Sep 3, 2014 at 9:51 AM, Robert Haas wrote:
>>> INSERT INTO upsert(key, val) VALUES(1, 'insert') ON CONFLICT WITHIN
>>> upsert_pkey UPDATE SET val = 'update';
>>
>> It seems to me that it would be better to specify a conflicting col
On Mon, Oct 6, 2014 at 6:12 PM, Ali Akbar wrote:
> User apaan is me. When i added to the commitfest, the patch is listed there
> by me (apaan).
That's fine I think, it's just for tracking who made the changes in
the CommitFest app. What actually matters is what you write in the
"Author" field, wh
I'm a bit confused about who I should be replying to, but since you
were the last one with a patch...
On Mon, Oct 6, 2014 at 11:44 AM, Ali Akbar wrote:
> Thanks for the review. Attached the formatted patch according to your
> suggestion.
+ select * from generate_series(0.1::numeric, 10.0::numeri
On Mon, Oct 6, 2014 at 4:27 PM, Fabrízio de Royes Mello
wrote:
> create_index_if_not_exists_v7.patch
Looks good to me. Marking ready for committer.
If you have any feedback about my reviews, I would gladly hear it. I'm
quite new to this.
PS: You seem to be submitting many patches, but have you
On Mon, Oct 6, 2014 at 5:12 AM, Marti Raudsepp wrote:
> On Mon, Oct 6, 2014 at 4:17 AM, Fabrízio de Royes Mello
> wrote:
>> CREATE INDEX ... [ IF NOT EXISTS [ name ] ] ON ...
> I think this one is wrong now.
I see now, I think you meant:
CREATE INDEX ... [ [ IF NOT EXISTS ] na
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
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 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 2:15 AM, Marti Raudsepp wrote:
> + ereport(NOTICE,
> + (errcode(ERRCODE_DUPLICATE_TABLE),
> + errmsg("relation \"%s\" already exists, skipping",
> + indexRelationName)));
>
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 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
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 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
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 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 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 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 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
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 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
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 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 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 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 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 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 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, 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 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 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 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.
I believe the reason why this
On Fri, Apr 25, 2014 at 8:58 PM, Josh Berkus wrote:
> Well, I've already had collisions with UUID-OSSP, in production, with
> only around 20 billion values. So clearly there aren't 122bits of true
> randomness in OSSP. I can't speak for other implementations because I
> haven't tried them.
Inte
On Fri, Apr 25, 2014 at 3:36 AM, Tom Lane wrote:
> Of course, the weak spot in this analysis is the assumption that there
> are actually 122 independent bits in the value. It's not difficult to
> imagine that systems with crummy random() implementations might only have
> something like 32 bits wo
On Thu, Apr 24, 2014 at 8:40 PM, Josh Berkus wrote:
> A pseudo-random UUID is frankly pretty
> useless to me because (a) it's not really unique
This is FUD. A pseudorandom UUID contains 122 bits of randomness. As
long as you can trust the random number generator, the chances of a
value occurring
On Wed, Apr 23, 2014 at 11:26 AM, David Rowley wrote:
> but for a long time I've thought that it would be nice if
> PostgreSQL came with an example database that had a number of tables,
> perhaps that mock up some easy to relate to real-world application. These
> would be very useful to use as exa
On Sun, Mar 23, 2014 at 7:57 AM, Amit Kapila wrote:
> Anyone has any objection for this behaviour difference between
> usage of ::regclass and to_regclass()?
No, I think that makes a lot of sense given the behavior -- if the
object is not there, to_regclass() just returns NULL. It doesn't
require
On Tue, Mar 18, 2014 at 9:29 PM, Petr Jelinek wrote:
> Attached V4 uses "shadowed-variables" instead of "shadow".
I think that should be "shadowed_variables" for consistency; GUC
values usually have underscores, not dashes. (e.g.
intervalstyle=sql_standard, backslash_quote=safe_encoding,
synchron
On Tue, Mar 11, 2014 at 1:24 PM, Parul Lakkad wrote:
> I am trying to figure out when disk is used to store intermediate results
> while performing joins in postgres.
Joins can also cause a Nested Loop+Materialize plan, which spills to
disk if the materialize result set is too large for work_mem.
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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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
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 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
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
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 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
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
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 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
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
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
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
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 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 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
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 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
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:/
1 - 100 of 285 matches
Mail list logo
