Greg Stark wrote:
> On Thu, Jul 16, 2009 at 9:07 PM, Roman Kononov wrote:
>> test=# create table junk(i int);
>> CREATE TABLE
>> test=# select * from junk left outer join (select coalesce(i,1) as x,
>> coalesce(i,2) as y from junk) t on coalesce(i,3)=x and coalesce(i,4)=y and
>> coalesce(i,5)=x;
>>
Heikki Linnakangas wrote:
> 2. make_inner_pathkeys_for_merge() should have created sort order (x, y,
> x) for the inner side.
On further thought, that would make no sense. Sort order (x, y) is
always equivalent to (x, y, x).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
-
One of our customers discovered that by replacing <>TRUE with =FALSE in
a query of a table containing 750.000 records reduced the query time
from about 12 seconds to about 60 milliseconds!
The problematic query looks like this:
SELECT * FROM AlarmLogg WHERE Logg_avsluttet <> TRUE AND
Alarm_status=
Ok,
So this took a while, but here's your test case.
Turns out to be quite small actually ;)
create table t1 (id int);
CREATE FUNCTION tr_t1_after_iud()
RETURNS trigger
LANGUAGE 'plpgsql'
VOLATILE
STRICT
SECURITY INVOKER
AS 'DECLARE
BEGIN
RAISE NOTICE ''%'', ROW(NEW.*);
SELECT 1/0;
RET
On Friday 17 July 2009 11:12:41 Jan-Ivar Mellingen wrote:
> One of our customers discovered that by replacing <>TRUE with =FALSE in
> a query of a table containing 750.000 records reduced the query time
> from about 12 seconds to about 60 milliseconds!
> This is a dramatical difference, but I cann
The following bug has been logged online:
Bug reference: 4927
Logged by: handling numeric literals with dots in psql \copy
command
Email address: filip.rembialkow...@gmail.com
PostgreSQL version: 8.4.0
Operating system: Linux
Description:psql does "spoil" the query be
It might be that your column may be NULL as well as TRUE or FALSE. I
am no expert in this matter though.
/M
On Fri, Jul 17, 2009 at 10:12 AM, Jan-Ivar
Mellingen wrote:
> One of our customers discovered that by replacing <>TRUE with =FALSE in
> a query of a table containing 750.000 records reduced
On Friday 17 July 2009 12:45:47 Mikael Krantz wrote:
> It might be that your column may be NULL as well as TRUE or FALSE. I
> am no expert in this matter though.
Nulls also need to be considered when attempting to substitute purportedly
equivalent clauses. But in this case it wouldn't actually m
Jan-Ivar Mellingen writes:
> One of our customers discovered that by replacing <>TRUE with =FALSE in
> a query of a table containing 750.000 records reduced the query time
> from about 12 seconds to about 60 milliseconds!
This is not a bug. The set of operators that are indexable is well
documen
Peter Eisentraut writes:
> ... But again, this is data type specific knowledge.
Actually, now that I think about it, the planner already has
datatype-specific knowledge about boolean equality (see
simplify_boolean_equality). It would take just a few more lines of code
there to recognize "x <> tr
I don't think it even has to be so specific. We should just always
rewrite bool <> bool into bool = NOT bool.
Hmm. That only has a 50/50 chance of creating an indexable clause.
Perhaps we could even rewrite it as "a = NOT b AND NOT a = b".
--
Greg
On 2009-07-17, at 3:21 PM, Tom Lane wro
Frank van Vugt writes:
> So this took a while, but here's your test case.
> Turns out to be quite small actually ;)
Hmm ... the relevant code change seems to have been
http://archives.postgresql.org/pgsql-committers/2009-04/msg00127.php
I think I might have been overenthusiastic in trying to
Heikki Linnakangas writes:
> Version 8.3 has the same bug, apparently introduced along with the
> equivalence classes. In 8.2, the merge condition is reduced into (i=x
> AND i=y), IOW the planner eliminates the duplicate condition. I believe
> 8.2 would otherwise have the same problem as well.
Th
Hi Tom,
> Hmm ... the relevant code change seems to have been
> http://archives.postgresql.org/pgsql-committers/2009-04/msg00127.php
Well, though not during beta, the field testing did pay off ;)
> I think I might have been overenthusiastic in trying to free resources
> during a subtransaction a
I wrote:
> I think what this case may show is simply that the consistency
> checking I added to create_mergejoin_plan in 8.3 is too strict.
> Not quite convinced yet though.
After further review I think that is the correct approach to take.
The proximate cause of the problem is that
find_mergecla
handling numeric literals with dots in psql copy command escreveu:
> fi...@filip=# \copy ( select 1.23::numeric as num ) to 'out.csv' with csv
> header
> ERROR: syntax error at or near "."
> LINE 1: COPY ( select 1 . 23::numeric as num ) TO STDOUT CSV HEADER
> ^
> \copy: ER
Euler Taveira de Oliveira writes:
> Why are we analysing the query there? One possible fix is to remove the '.' as
> delimiter in strtokx(). The trivial patch is attached.
Surely that would break a lot of other cases.
regards, tom lane
--
Sent via pgsql-bugs mailing lis
"Roman Kononov" writes:
> Description:too few pathkeys for mergeclauses
I've applied a patch for this. Thanks for the report.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.post
Tom Lane escreveu:
> Euler Taveira de Oliveira writes:
>> Why are we analysing the query there? One possible fix is to remove the '.'
>> as
>> delimiter in strtokx(). The trivial patch is attached.
>
> Surely that would break a lot of other cases.
>
Why? Even if it can't catch all cases when we
19 matches
Mail list logo
