> "Jeff" == Jeff Janes writes:
Jeff> From: https://www.postgresql.org/docs/9.4/static/sql-createtable.html
Jeff> "The access method must support amgettuple (see Chapter 55); at
Jeff> present this means GIN cannot be used. Although it's allowed, there is
Jeff> little point in using B-tree
> "Robert" == Robert Haas writes:
Robert> Hmm, so sizeof() has different semantics in C vs. C++?
No. '1' has different semantics in C vs C++. (In C, '1' is an int,
whereas in C++ it's a char. It so happens that (sizeof '1') is the only
case which is valid in both C and C++ where this makes
> "Tom" == Tom Lane writes:
> Emre Hasegeli writes:
>> Attached patches add SP-GiST support to the inet datatypes.
Tom> I started to look at this patch. The reported speedup is pretty
Tom> nice, but ...
The builtin gist support for inet seems quite surprisingly slow; ip4r
beats it int
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> While playing with LATERAL along with some aggregates in
Jeevan> sub-query, I have observed somewhat unusual behavior.
Simpler example not needing LATERAL:
select array(select sum(x+y) from generate_series(1,3) y group by y)
from
>>>>> "Andrew" == Andrew Gierth writes:
>>>>> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> While playing with LATERAL along with some aggregates in
Jeevan> sub-query, I have observed somewhat unusual behavior.
Andrew&g
> "Tom" == Tom Lane writes:
Tom> I'm not sure if it's worth trying to distinguish whether the Param
Tom> is inside any aggregate calls or not. The existing code gets the
Tom> right answer for
Tom> select array(select x+sum(y) from generate_series(1,3) y group by y)
Tom> from generat
>>>>> "Andrew" == Andrew Gierth writes:
>>>>> "Tom" == Tom Lane writes:
Tom> I'm not sure if it's worth trying to distinguish whether the Param
Tom> is inside any aggregate calls or not.
How about:
--
Andrew (irc:Rhodi
> "Pavel" == Pavel Stehule writes:
Pavel> The result should not depend on GUC - hashagg on/off changing
Pavel> output - it is error.
I don't think anyone's suggesting leaving it unfixed, just whether the
fix should introduce unnecessary rescans of the aggregate input.
--
Andrew (irc:Rhod
> "Tom" == Tom Lane writes:
Tom> Hm, I was just working on inserting something of the sort into
Tom> ExecInitAgg. But I guess we could do it in the planner too. Will
Tom> run with your approach.
Tom> I think it's a bit too stupid as-is, though. We don't need to
Tom> recalculate for P
> "Thom" == Thom Brown writes:
Thom> This doesn't apply cleanly to latest master. Could you please
Thom> post a rebased patch?
Sure.
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index c9e0a3e..480a07e 100644
--- a/src/backend/
> "Mark" == Mark Dilger writes:
Mark> On linux/gcc the patch generates a warning in nodeAgg.c that is
Mark> fairly easy to fix. Using -Werror to make catching the error
Mark> easier, I get:
what gcc version is this exactly?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers maili
> "Mark" == Mark Dilger writes:
Mark> Hi Andrew,
Mark> Reviewing the patch a bit more, I find it hard to understand the
Mark> comment about passing -1 as a flag for finalize_aggregates. Any
Mark> chance you can spend a bit more time word-smithing that code
Mark> comment?
Sure.
How do
> "Mark" == Mark Dilger writes:
Mark> Hi Andrew,
Mark> Reviewing the patch a bit more, I find it hard to understand the
Mark> comment about passing -1 as a flag for finalize_aggregates. Any
Mark> chance you can spend a bit more time word-smithing that code
Mark> comment?
Actually, ign
This came up recently on irc:
create type t1 as (a integer, b integer);
create type t2 as (p t1, q t1);
create function null_t2() returns t2 language sql
as $f$ select null::t2; $f$;
Now consider the following plpgsql:
declare
v t2;
begin
v := null_t2();
raise info 'v is null = %', v is
I've been assisting Atri with development of an implementation of
GROUPING SETS, beginning with a one-pass implementation of ROLLUP.
Two issues have arisen regarding the API for calling aggregate
transition and final functions that I think need answering now,
since they relate to changes in 9.4.
1
> "Tom" == Tom Lane writes:
>> Doing rollup via GroupAggregate by maintaining multiple transition
>> values at a time (one per grouping set) means that the transfn is
>> being called interleaved for transition values in different
>> contexts. So the question becomes: is it wrong for the t
> "Tom" == Tom Lane writes:
Tom> Another approach would be to remove AggGetPerAggEContext as such
Tom> from the API altogether, and instead offer an interface that
Tom> says "register an aggregate cleanup callback", leaving it to the
Tom> agg/window core code to figure out which context t
> "Tom" == Tom Lane writes:
>> Do we want a decision on the fn_extra matter first, or shall I do
>> one patch for the econtext, and a following one for fn_extra?
Tom> I think they're somewhat independent, and probably best patched
Tom> separately. In any case orderedsetagg.c's use of fn
> "Tom" == Tom Lane writes:
Tom> If we're going to do that, I think it needs to be in 9.4. Are
Tom> you going to work up a patch?
How's this? (applies and passes regression on 9.4 and master)
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executo
Here are two more, cumulative with the previous patch and each other:
The first removes the assumption in ordered_set_startup that the
aggcontext can be cached in fn_extra, and puts it in the transvalue
instead.
The second exposes the OSA* structures in a header file, so that
user-defined ordered
> "Tom" == Tom Lane writes:
>> How's this? (applies and passes regression on 9.4 and master)
Tom> Pushed with minor cosmetic adjustments.
Thanks!
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
Spent some time analyzing a severe performance regression on 9.1->9.3
upgrade for a user on IRC. Narrowed it down to this:
commit 807a40c5 fixed a bug in handling of (new in 9.2) functionality
of ScalarArrayOpExpr in btree index quals, forcing the results of
scans including such a qual to be treat
> "Tom" == Tom Lane writes:
>> I've experimented with the attached patch, which detects when this
>> situation might have occurred and does another pass to try and
>> build ordered scans without the SAOP condition. However, the
>> results may not be quite ideal, because at least in some t
[snip]
This thread seems to have gone quiet - is it time for me to just go
ahead and commit the thing anyway? Anyone else want to weigh in?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
> "Andres" == Andres Freund writes:
Andres> Changes to advance_aggregates() are, in my experience, quite
Andres> likely to have performance effects. This needs some
Andres> performance tests.
[...]
Andres> Looks like it could all be noise, but it seems worthwhile to
Andres> look into s
> "Andres" == Andres Freund writes:
>> - Assert(newphase == 0 || newphase == aggstate->current_phase + 1);
>> + Assert(newphase <= 1 || newphase == aggstate->current_phase + 1);
Andres> I think this somewhere in the file header needs an expanded
Andres> explanation about what these "
> "Mark" == Mark Dilger writes:
Mark> You define DiscreteKnapsack to take integer weights and double
Mark> values, and perform the usual Dynamic Programming algorithm to
Mark> solve. But the only place you call this, you pass in NULL for
Mark> the values, indicating that all the values a
> "Mark" == Mark Dilger writes:
Mark> Is there a performance test case where this patch should shine
Mark> brightest? I'd like to load a schema with lots of data, and run
Mark> a grouping sets query, both before and after applying the patch,
Mark> to see what the performance advantage is
> "Andres" == Andres Freund writes:
Andres> We usually cast the result of palloc.
>> Rough count in the backend has ~400 without casts to ~1350 with, so
>> this doesn't seem to have been consistently enforced.
Andres> Yea, but we're still trying.
Well, a lot of the uncasted ones are in
> "Andres" == Andres Freund writes:
Andres> a) cast result of lfirst/lnext/whatnot.
Again, what we need here is something like
#define lfirst_node(_type_, l) (castNode(_type_, lfirst(l)))
etc.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
> "Peter" == Peter Eisentraut writes:
> On 4/3/17 02:44, Ashutosh Bapat wrote:
>> [1] says that id.attribute is supported in stylesheets version
>> 1.77.1. Do I need to update stylesheets version? How do I do it?
>> Any help will be appreciated.
Peter> The oldest version among the ones
> "Vicky" == Vicky Vergara writes:
Vicky> UPDATE pg_proc SET [...]
Vicky> So, I want to know how "safe" can you consider the second
Vicky> method, and what kind of other objects do I need to test besides
Vicky> views.
Speaking from personal experience (I did this in the upgrade script f
> "Andreas" == Andreas Seltenreich writes:
Andreas> Hi,
Andreas> testing master at f0e44021df with a loopback postgres_fdw
Andreas> installed, I see lots of crashes on queries joining foreign
Andreas> tables with various expressions. Below is a reduced recipe
Andreas> for the regressi
> "Tom" == Tom Lane writes:
Tom> Experimentation shows that actually, the standard regression tests
Tom> provide dozens of opportunities for find_relation_from_clauses to
Tom> fail on non-RestrictInfo input. However, it lacks any IsA check,
In a discussion with Andres on the hash groupin
> "David" == David E Wheeler writes:
David> And it works great, including in PL/pgSQL functions, except in
David> an exception block. When I run this:
David> BEGIN;
David> CREATE OR REPLACE FUNCTION foo(
David> ) RETURNS BOOLEAN IMMUTABLE LANGUAGE PLPGSQL AS $$
David>
> "David" == David E Wheeler writes:
>> If you change this to EXCEPTION WHEN division_by_zero THEN, the
>> reported error becomes:
>>
>> ERROR: malformed array literal: "foo"
>> LINE 1: SELECT things || 'foo'
David> So the issue stands, yes?
Tom's response has the explanation of why
> "Thomas" == Thomas Munro writes:
>> SomeType *x = (SomeType *) lfirst(l);
>>
>> (in my code I tend to omit the (SomeType *), which I dislike because
>> it adds no real protection)
Thomas> Just BTW, without that cast it's not compilable as C++, so I'm
Thomas> guessing that Peter E wi
The distinction between the standard representation of '{}' as an array
with zero dimensions and nonstandard representations as a 1-dimensional
array with zero elements has come up in a couple of contexts on the IRC
channel recently.
First is contrib/intarray, _AGAIN_ (see past bugs such as #7730)
> "Tom" == Tom Lane writes:
>> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730):
>> ...
>> I plan to fix this one properly, unless anyone has any objections.
Tom> Just to clarify, what do you think is "properly"?
I would say, that any time an intarray function returns an
> "Alexander" == Alexander Kuzmenkov writes:
Alexander> Structurally, the patch consists of two major parts: a
Alexander> specialized executor node
Why?
It strikes me that the significant fact here is not that we're doing
count(*), but that we don't need any columns from the bitmap heap s
> "Pavan" == Pavan Deolasee writes:
Pavan> I am attaching a patch that throws a similar ERROR during
Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we
Pavan> always decide to use sort-based implementation for grouping, but
Pavan> do not check if the columns support ord
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> Unfortunately I've been delayed over the past couple of days,
Andrew> but I have Thomas' latest patchset in hand and will be working
Andrew> on it over the rest of the week. Status update by 23:59 BS
> "Thomas" == Thomas Munro writes:
Thomas> That accidentally removed a comment that I wanted to keep.
Thomas> Here is a better version.
I plan to commit this soon; if anyone has any comment to make, now would
be a good time.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailin
> "Thomas" == Thomas Munro writes:
Thomas> Thanks both for the review. New version of patch #2 attached.
I'm looking to commit this soon; if anyone has any further comment now
would be a good time to speak up.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-h
> "Noah" == Noah Misch writes:
Noah> This PostgreSQL 10 open item is past due for your status update.
Noah> Kindly send a status update within 24 hours,
oops, sorry! I forgot to include a date in the last one, and in fact a
personal matter delayed things anyway. I expect to have this wrapp
> "Noah" == Noah Misch writes:
Noah> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is
Noah> long past due for your status update. Please reacquaint yourself
Noah> with the policy on open item ownership[1] and then reply
Noah> immediately. If I do not hear from you by 2017-
Commits pushed.
Unless I broke the buildfarm again (which I'll check up on later), or
some new issue arises with the fixes, this should close all 3 related
items for transition tables.
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
> "Thomas" == Thomas Munro writes:
Thomas> Here it is. Added to open items.
On it.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>>>>> "Andrew" == Andrew Gierth writes:
>>>>> "Thomas" == Thomas Munro writes:
Thomas> Here it is. Added to open items.
Andrew> On it.
Committed.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hack
> "Thomas" == Thomas Munro writes:
>> [...]
>> T_NamedTuplestoreScan can be produced by outfuncs.c with tagname
>> NAMEDTUPLESTORESCAN but that tagname is not recognized by readfuncs.c
>> [...]
>>
>> That revealed a defect in commit
>> 18ce3a4ab22d2984f8540ab480979c851dae5338 which I
> "Thomas" == Thomas Munro writes:
Thomas> So, afterTriggers.query_stack is used to handle the reentrancy
Thomas> that results from triggers running further statements that
Thomas> might fire triggers. It isn't used for dealing with extra
Thomas> ModifyTable nodes that can appear in a pl
> "Robert" == Robert Haas writes:
Robert> unless some other committer volunteers. (Of course, anyone
Robert> could step in to do the work, as Thomas already has to a
Robert> considerable degree, but without a committer involved it
Robert> doesn't fix the problem.)
I can probably take th
> "Robert" == Robert Haas writes:
Robert> So, Andrew, are you running with this, or should I keep looking
Robert> into it?
I have it; I will post a status update before 23:59 BST on 11 Jun.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
> "Robert" == Robert Haas writes:
Robert> I don't see a reason why MakeTransitionCaptureState needs to
Robert> force the tuplestores into TopTransactionContext or make them
Robert> owned by TopTransactionResourceOwner.
Nor do I, and I'm pretty sure it's leaking memory wholesale within a
t
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> I have it; I will post a status update before 23:59 BST on 11
Andrew> Jun.
This is that status update. I am still studying Thomas' latest patch
set; as I mentioned in another message, I've confirmed a m
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> I will post a further status update before 23:59 BST on 14th
Andrew> Jun.
Unfortunately I've been delayed over the past couple of days, but I have
Thomas' latest patchset in hand and will be working on it
(From IRC discussion with Andreas about some sqlsmith errors)
Commit 278148907a9 changed close_ps in geo_ops.c to return SQL NULL in
the event that a valid result point was not found (rather than crashing
or failing an assert).
But close_ps is called with DirectFunctionCall from other close_*
fun
>>>>> "Andrew" == Andrew Gierth writes:
Andrew> The other is that in subquery_planner, the optimization of
Andrew> converting HAVING clauses to WHERE clauses is suppressed if
Andrew> parse->groupingSets isn't empty. (It is empty if there's e
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> This will fail too.
This is in addition to your patch, not instead of it.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi
Jeevan> It looks like we have broken the ROW expression without
Jeevan> explicit ROW keyword in GROUP BY.
Andres has given the short version, but here's the long version:
In the spec, GROUP BY ROW(a,b) is an error, while GROUP BY (a,b) is
ex
Boszormenyi Zoltan wrote:
>> This parser hackery is of course somewhat ugly. But given the objective
>> of implementing the spec's unnest syntax, it seems to be the least ugly
>> of the possible approaches. (The hard part of doing it any other way
>> would be generating the description of the resul
> "Peter" == Peter Eisentraut writes:
Peter> Please fix compiler warnings:
Someone should do the same in WaitForBackgroundWorkerStartup so that
building with -Werror works.
New patch coming shortly.
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Before getting to the administrivia of the patch review, I think it's
worth a bit of analysis on why the planner behaves as it does.
The example query:
explain analyze select * from
( select oid, * from pg_class order by oid) as c
join
( select * from pg_attribute a order by attrelid)
> "Alexander" == Alexander Korotkov writes:
Alexander> 2) NaN coordinates should be processed in GiST index scan
Alexander> like in sequential scan.
postgres=# select * from pts order by a <-> '(0,0)' limit 10;
a
--
(1,1)
(7,nan)
(9,nan)
(11,nan)
(4,nan)
(nan,6)
(2,
> "Josh" == Josh Berkus writes:
Josh> The issue isn't that, it's that git apply is just buggy and
Josh> can't tell the difference between a new file and a modified
Josh> one.
It's not the fault of git apply; the patch contained explicit
annotations on all the files claiming that they were
> "Jeff" == Jeff Janes writes:
Jeff> I used "git diff" configured to use
Jeff> src/tools/git-external-diff, as described here:
hmm...
so that git-external-diff script is trying to fake git diff output,
including using 'diff -git' and index lines, but the context-diff
output wouldn't work
> "Robert" == Robert Haas writes:
>> Someone should do the same in WaitForBackgroundWorkerStartup so
>> that building with -Werror works.
Robert> I don't get a warning there. Can you be more specific about
Robert> the problem?
bgworker.c: In function 'WaitForBackgroundWorkerStartup':
b
> "dlight" == dlight writes:
dlight> So if I run function 1 with varible inside the query in
dlight> one session it's replan each time.
dlight> But if whant to teling postgres do not doing this, what shoud
dlight> i do?
dlight> We have more than 1 runs in one session with vari
> "Robert" == Robert Haas writes:
>> bgworker.c: In function 'WaitForBackgroundWorkerStartup':
>> bgworker.c:866: warning: 'pid' may be used uninitialized in this function
Robert> Does the attached patch fix it for you?
It compiles without error and looks ok...
--
Andrew (irc:RhodiumTo
> "Heikki" == Heikki Linnakangas writes:
Heikki> I've spent some time reviewing this patch - looks pretty
Heikki> good! I'm not through yet, but I wanted to post an
Heikki> update. Attached is a new version, with some modifications I
Heikki> made. Notably:
Heikki> I refactored the gramm
> "Merlin" == Merlin Moncure writes:
>> Who is pgFoundery administrator or board member now? I would like
>> to send e-mail them. At least, it does not have information and
>> support page in pgFoundery homepage.
Merlin> I have not been able to get in contact with Marc either to
Merlin>
> "Pavel" == Pavel Stehule writes:
>> I found so following error message is not too friendly (mainly because
>> this functionality will be new)
>>
>> postgres=# select dense_rank(3,3,2) within group (order by num desc, odd)
>> from test4;
>> ERROR: Incorrect number of arguments for hy
OK, let's try to cover all the bases here in one go.
First, the spec definition of WITH ORDINALITY simply says that the
column name in the result is not equivalent to any other identifier in
the same (including the ). It is
clear that the intention of the spec is that any non-positional
reference
Dean Rasheed said:
> To recap, the options currently on offer are:
>
> 1). Make FILTER a new partially reserved keyword, accepting that that
> might break some users' application code.
>
> 2). Make FILTER unreserved, accepting that that will lead to syntax
> errors rather than more specific error m
Tom Lane said:
> Agreed, separating out the function-call-with-trailing-declaration
> syntaxes so they aren't considered in FROM and index_elem seems like
> the best compromise.
>
> If we do that for window function OVER clauses as well, can we make
> OVER less reserved?
Yes.
At least, I tried it
Noah Misch said:
> I twitched upon reading this, because neither ORDER BY nor FILTER preclude
> the aggregate being MIN or MAX. Perhaps Andrew can explain why he put
> aggorder there back in 2009.
The bottom line is that I intentionally avoided assuming that an agg with an
aggsortop could only b
The spec defines two types of aggregate function classed as "ordered set
function", as follows:
1. An "inverse distribution function" taking one argument (which must be
a grouped column or otherwise constant within groups) plus a sorted
group with exactly one column:
=# SELECT (func(p)
Josh Berkus wrote:
> On 07/17/2013 08:15 PM, Andrew Gierth wrote:
> > The spec defines two types of aggregate function classed as "ordered set
> > function", as follows:
> >
> > 1. An "inverse distribution function" taking one argument (which must b
Josh Berkus wrote:
> Hah, I didn't realize that our ordered aggregate syntax even *was* spec.
The spec defines agg(x order by y) only for array_agg and xmlagg; the
generalization to arbitrary other aggregates is our extension. (But
kind of obvious really.)
> > Our implementation does heavily reus
Greg Stark said:
> So the more I look at this patch the fewer things I want to change in
> it. I've several times thought I should make an improvement and then
> realized I was really just making unnecessary tweaks that didn't
> really make much difference.
It's almost as though we actually though
Tom Lane said:
> I haven't read this patch, but that comment scares the heck out of me.
> Even if the patch isn't broken today, it will be tomorrow, if it's
> making random changes like that in data structure semantics.
> Also, if you're confused, so will be everybody else who has to deal with
> th
Ok, since Atri posted our work-so-far and there's not been much
comment, I'll outline here my proposed plan of attack.
Rather than, as in the WIP patch, using the agg finalfn to validate
the split between normal args and ORDER BY args, I propose this:
Firstly, as in the WIP patch,
func(a) with
Tom Lane said:
> If you yourself are still finding bugs in the code as of this afternoon,
> onlookers could be forgiven for doubting that the code is quite as
> readable or ready to commit as all that.
Right, and we all know that all code is perfect when committed. sheesh.
(This is actually the f
As failures to use a generic plan goes, that one's fairly tame. I've
seen much worse. For example:
PREPARE foo(integer[]) AS SELECT * FROM complexview WHERE id = ANY ($1);
where the caller typically supplies 1-5 array elements (or any number
less than 10, because generic parameter arrays are assu
Stephen Frost said:
> [stuff about foreign tables]
I think the issue with foreign tables is probably moot because if you
_did_ want to have some types of foreign tables with a fixed
ordinality, you'd probably also want qual pushdown to work for it
(i.e. so that WHERE rownum=123 doesn't have to fil
Noah Misch said:
> Other aggregates based on this syntax might not desire such type unification.
Then there would have to be some way to distinguish that. Maybe those could
have -1 and the standard hypothetical set functions -2, with some flag in
CREATE AGGREGATE to sort it out.
> Having parse an
Tom Lane said:
> If we did it with a WithOrdinality expression node, the result would
> always be of type RECORD, and we'd have to use blessed tuple
> descriptors to keep track of exactly which record type a particular
> instance emits. This is certainly do-able (see RowExpr for
> precedent).
May
I propose the following patch (which goes on top of the current
ordinality one) to implement the suggested grammar changes.
I think this is the cleanest way, and I've tested that it both
passes regression and allows constructs like WITH time AS (...)
to work.
--
Andrew (irc:RhodiumToad)
*** a/sr
An issue that comes up regularly on IRC is that text search queries,
especially on relatively modest size tables or for relatively
non-selective words, often misplan as a seqscan based on the fact that
to_tsvector has procost=1.
Clearly this cost number is ludicrous.
Getting the right cost estima
> "Tom" == Tom Lane writes:
Tom> Nyet ... at least not without you actually making that argument,
Tom> with numbers, rather than just handwaving. We use 100 for plpgsql
Tom> and suchlike functions. I'd be OK with making it 10 just on
Tom> general principles, but claiming that it's as ex
> "Marko" == Marko Tiikkaja writes:
Marko> Hi,
Marko> My colleague Per Lejontand brought to my attention that when
Marko> dumping views with circular dependencies from a postgres version
Marko> older than 9.4 using a recent pg_dump, the SQL looks something
Marko> like the following:
M
> "Tom" == Tom Lane writes:
>> I've wondered for a while whether this wouldn't have been better
>> handled as:
>> create view qwr(colnames...) as select null::type1, null::type2, ...;
>> /* ... */
>> create or replace view qwr as ...;
Tom> Yeah, possibly. The existing pg_dump coding
> "Peter" == Peter Geoghegan writes:
Peter> I attach a slightly tweaked version of Andrew's original.
You changed this:
static int
comparetup_datum(const SortTuple *a, const SortTuple *b, Tuplesortstate *state)
{
-int compare;
+int32 compare;
compare = Apply
>> if test "`(eval $ac_link 2>&1 1>&5)`" = "" && test "`(eval
>> $ac_compile 2>&1 1>&5)`" = ""; then
FWIW, I happened to run into this recently on IRC with someone having
compile problems on FreeBSD (10.1); they were using some nonstandard
compile flags, and configure's pthread test was breakin
> "Max" == Max Filippov writes:
Max> Sorry, I must be not clear enough: why checking compiler/linker
Max> output instead of checking their exit code or presence of produced
Max> object/ executable files?
Going by the comment some lines above, my guess would be "because some
compilers acce
> "Robert" == Robert Haas writes:
>> Then maybe stderr tests should grep output for a specific option,
>> the one we're currently testing, not just any noise?
Robert> That sounds awfully fragile to me. It can't really be safe to
Robert> assume we know precisely what the warning messages
> "Peter" == Peter Geoghegan writes:
Peter> Attached is a revision of this patch, that I'm calling v2. What
Peter> do you think, Andrew?
"No." is I think the best summary of my response.
I strongly suggest whichever committer ends up looking at this consider
my original version unchanged
> "Peter" == Peter Geoghegan writes:
>> This is simply wrong. The reason why the cost model (in my version)
>> tracks non-null values by having its own counter is precisely
>> BECAUSE the passed-in memtupcount includes nulls, and therefore the
>> code will UNDERESTIMATE the fraction of su
Was there some reason why you added #include "utils/memutils.h"?
Because I don't see anything in your patch that actually needs it.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
A couple of places (adt/timestamp.c and pgbench.c) have this:
#ifndef INT64_MAX
#define INT64_MAX INT64CONST(0x7FFF)
#endif
#ifndef INT64_MIN
#define INT64_MIN (-INT64CONST(0x7FFF) - 1)
#endif
On the other hand, int8.c uses the INT64_MIN expression directly in
1 - 100 of 494 matches
Mail list logo
