Hi there folks
I created custom type, and attempt to create gist indexing for it, to
make search wind quick.
on select from * where something 'something'; I get:
WARNING: problem in alloc set GiST temporary context: detected write
past chunk end in block 0x843e6e0, chunk 0x843e994
Can
Seems like decompress and compress were offending here, simply
removing them from gist index create helped.
But, I still get on explain analyze that seqscan was used, rather
than gist. Even tho ~ operator is defined for gist, and that seqscan
is set to false.
On 2005-10-28, at 00:24, gj
Sorry for all this crap, this is bullocks.
reason was, one of internal functions didn't filled out length value,
and since the type is variable length, we had trouble.
Postgres wasn't copying anything, since length was 0, hence the NULL -
key.
So here's little request. Could someone please put
On 2005-10-28, at 07:37, Oleg Bartunov wrote:
On Fri, 28 Oct 2005, Christopher Kings-Lynne wrote:
Grzegorz - it'd be great if you submitted documentation
improvements :)
I don't see any GiST specific problem in Grzegorz's case.
Other than just stupid bug, I know. It was just hard to
Hi folks
We're developing here gist index (which works finally, and I remember
about writing some docs about it).
I have few fprintf(stderr,) in function that converts internal
rep. into string. I was really supprised to see them on me screen when :
select count(b) from blah where b ~
Yes, sorry for the mess. The problem was somewhere else (not quite
well written log procedure issuing conversion used for logging, even
tho log was off).
--
GJ
If we knew what we were doing, it wouldn't be called Research, would
it? - AE
---(end of
Hi folks
I have all operators required for b-tree, gist up here, and gist
index defined. But still order by custom_type won't work.
I have kind of wild card masks in my type definition, so b-tree won't
work. But still, do I need to define b-tree index as such for order
by to work ?
Perhaps
On 2005-11-18, at 22:53, Tom Lane wrote:
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
I have all operators required for b-tree, gist up here, and gist
index defined. But still order by custom_type won't work.
Define won't work ... what happens?
Wildcards cause things not to work
aye aye Sir.
--
GJ
If we knew what we were doing, it wouldn't be called Research, would
it? - AE
---(end of broadcast)---
TIP 6: explain analyze is your friend
Hi folks
my conquers with Gist index for custom type are nearly finished. It
is working as it is now, but there are few problems here and there.
One of em, being amount of disc space index it self takes. The type
stucture it self takes 160bytes. Adding 100.000 rows into table -
CREATE
On 2005-11-21, at 19:32, Martijn van Oosterhout wrote:
On Mon, Nov 21, 2005 at 04:58:25PM +0100, Grzegorz Jaskiewicz wrote:
my conquers with Gist index for custom type are nearly finished. It
is working as it is now, but there are few problems here and there.
One of em, being amount of disc
On 2005-11-22, at 15:45, Tom Lane wrote:
Kevin McArthur [EMAIL PROTECTED] writes:
This is acceptable to create a unique constraint, however, we
cannot mark
the column unique, without defining btree operators, which clearly
are not
possible for sorting. Is there any way to base the
On 2005-11-22, at 16:39, Martijn van Oosterhout wrote:
On Tue, Nov 22, 2005 at 04:24:21PM +0100, Grzegorz Jaskiewicz wrote:
Translation: you do know how to define a sortable order (ie,
generate
the text version and compare); you're just too lazy to create the
operators to do it ...
We do
On 2005-11-22, at 17:17, Martijn van Oosterhout wrote:
On Tue, Nov 22, 2005 at 05:14:35PM +0100, Grzegorz Jaskiewicz wrote:
Ok, I hacked btree for my type, and surely I can have both btree and
gist at the same time on the same column.
/me is now going to have a look on btree_gist.
You don't
Hey folks,
I would like to learn more about execution path for a simple query,
that is going to be changed by a rule. I want to find out, why output
of 'affected rows' isn't always altered properly in rules rewriting
inserts and updates.
Can someone give me simple guide on where should I
http://pastebin.com/d39eb7643
never had problems on mac os x with head, for last 4 years or so.
PGP.sig
Description: This is a digitally signed message part
On 2008-10-06, at 20:59, Grzegorz Jaskiewicz wrote:
Hey folks,
I would like to learn more about execution path for a simple query,
that is going to be changed by a rule. I want to find out, why
output of 'affected rows' isn't always altered properly in rules
rewriting inserts
On 2008-10-08, at 01:57, Alvaro Herrera wrote:
Actually I find this to be a perfectly acceptable question for this
list. ISTM the answer, however, is to have a look at the
documentation
we have already in place ... perhaps starting with the Developer's FAQ
at
current cvs head won't compile here, linking problem. I did try make
distclean, etc:
Undefined symbols:
_dgettext, referenced from:
_errmsg_internal in elog.o
_elog_finish in elog.o
_errcontext in elog.o
_errhint in elog.o
_errdetail_log in elog.o
On 2008-10-09, at 21:25, Alvaro Herrera wrote:
Grzegorz Jaskiewicz wrote:
current cvs head won't compile here, linking problem. I did try make
distclean, etc:
Undefined symbols:
_dgettext, referenced from:
_errmsg_internal in elog.o
_elog_finish in elog.o
_errcontext
thickbook:backend gj$ gcc-4.2 -no-cpp-precomp -no-cpp-precomp -O2 -
Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-
statement -Wendif-labels -fno-strict-aliasing -fwrapv -L../../src/port
-Wl,-dead_strip_dylibs access/common/heaptuple.o access/common/
indextuple.o
On 2008-10-09, at 22:57, Alvaro Herrera wrote:
Grzegorz Jaskiewicz wrote:
On 2008-10-09, at 21:25, Alvaro Herrera wrote:
Yeah, my bad. What's the platform?
mac os x
Hmm, does your link line include -lintl? If not, does it successfully
link if you add it?
ld: library not found
head compiles ok now, panic's over ;)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2008-10-10, at 16:01, Tom Lane wrote:
Well, this discussion started with the conventional wisdom about be
conservative in what you send and liberal in what you accept. I'd
still resist emitting any UUID format other than the RFC-approved one,
but I don't see anything very wrong in being
I think it will be as expensive to app to convert UUID to standard
format, as it would be too postgrsql.
But if psql does it - everyone would expect it to do it right. You
can't possibly detect all forms of screwed up design, and expect
application to pick it up.
All I say, is I think it
so I wonder, quite few times ppl asked me about my-word database TOP %
PERCENT (and I guess ms-word db has it too).
Now that postgres has limit(subselect) - postgresql can do the same
thing. But, using a count(*) in subselects isn't very efficient. The
backend gets information from limit X,
that's a shame.
I figure, with the WITH ... AS .. you can kind of speed up counts,
just by doing it once - now. But still, it would be great to be able
to use PERCENT, against estimate.
After all, imagine a table FOO with 5 rows, and something like this:
WITH c AS (select count(*)/4 as n
On 2008-10-12, at 16:22, Hitoshi Harada wrote:
2008/10/12 Robert Haas [EMAIL PROTECTED]:
I wonder if this could be implemented using the window-function
infrastructure...
Yeah, actually window functions I am working now has percent_rank() or
something he wants. That is better than WITH
I won't send the full logs here, if someone's interested in it -
here's tar.bz2 version:
http://zlew.org/pg_regress.tar.bz2
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hmm, how could I miss that. but than:
thickbook:src gj$ ls -lahd /Users/gj/Projects/postgres-head/pgsql/src/
test/regress/results/
drwxr-xr-x 119 gj staff 4,0K 28 paź 19:14 /Users/gj/Projects/
postgres-head/pgsql/src/test/regress/results/
thickbook:src gj$ touch
On 2008-11-02, at 02:02, Greg Smith wrote:
Possible feedback topics:
-Setting the next round of values requires asking the user for some
input before making recommendations. Is it worth building a curses-
based interface to updating the values? That would be really
helpful for people
On 2008-11-13, at 19:33, Greg Stark wrote:
A statistic target of 400 fir a specific column may make sense but
even then I would recommend monitoring performance to ensure it
doesn't cause problems. As a global setting it's, IMHO, ridiculous.
If that's the situation, me thinks you guys
On 2008-11-19, at 21:53, Gregory Stark wrote:
So based on Graeme Job's T-SQL hack over at thedailywtf.com I
adapted the
T-SQL code to Postgres and got this. Thought others might find it
amusing.
hohoho, nice. That's even better than mine with recursive PI
generator :)
--
Sent via
this doesn't apply cleanly to head anymore, can you please post v21 ?
I would love to test it here :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2008-11-20, at 15:29, Peter Eisentraut wrote:
Well, the warning is explicitly put in there for this specific
function because you are supposed to process the return value. I'm
sure a more smarter compiler would even warn variable is assigned a
value that is never used. ;-) (Note
On 2008-11-20, at 11:08, Grzegorz Jaskiewicz wrote:
this doesn't apply cleanly to head anymore, can you please post v21 ?
I would love to test it here :)
bollocks, it's already in cvs head - isn't it ? ... :D
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 2008-12-06, at 11:29, David Lee Lambert wrote:
I use ORDER BY random() LIMIT :some_small_number frequently to get
a feel
for data. That always builds the unrandomized relation and then
sorts it. I
guess an alternate path for single-table queries would be to
randomly choose
a block
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries. I
don't think this can be done right now ... or can it? Has this
feature request surfaced in the past?
I currently need this as an extra security measure for a libpq
client
On 2008-12-06, at 18:30, Andrew Chernow wrote:
Grzegorz Jaskiewicz wrote:
On 2008-12-06, at 18:21, Andrew Chernow wrote:
Looking for a way to limited a user to a specific set of queries.
I don't think this can be done right now ... or can it? Has this
feature request surfaced
To be honest, for me back patching would mean only that I don't have
to recompile, and resend binaries to clients, after 8.1-8.3 upgrade
(to utilize enums, and domains).
I don't think it would break any apps tho.
so in my case, obviously +1 +1 :)
--
Sent via pgsql-hackers mailing list
if I may request one simple change/addition, Probably trivial to add,
but I don't have too much time to give away now to any other project
than one that pays my debts.
The default param that's in the middle. Would it be hard, or do anyone
objects against adding 'default' keyword there, so
Ok, how about
CREATE FUNCTION FOO (one int, two float8 default 3.14, three int[]
default '{6,7,8,90}');
and than SELECT FOO( 777, DEFAULT, '{1,2,3,4,5}');
I have no idea what SQL standard says in that case, all I know is that
keyword DEFAULT exists in it, and is used in queries for
On 21 Nov 2009, at 02:56, Josh Berkus wrote:
Would a patch that changes that have any chance of being accepted? Or is
the gain (not having to repeat the DEFAULT clause, and being able to
maintain it at one place instead of many) considered too small compared
to the risk of breaking
On 21 Jan 2010, at 09:37, Dave Page wrote:
In an attempt to pre-empt the normally drawn-out discussions about
what the next version of PostgreSQL will be numbered. the core team
have discussed the issue and following a lenghty debate lasting
literally a few minutes decided that the next
think also how people use SQL word , when calling ms sql server. They would
just say 'sql server' , and to some I had to explain that the little greedy
company didn't actually invented sql, hence it should be called ms sql
server...
so, -1 for dropping SQL word from me.
... and maybe the
if (p1 buf)
++ * --p1;
else {
++ * --p1; ???
does it even compile ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3 Mar 2010, at 17:41, Grzegorz Jaskiewicz wrote:
if (p1 buf)
++ * --p1;
else {
++ * --p1; ???
does it even compile ?
Oh, I can see, that it is *(--p1)++ ,mea culpa.
Which doesn't change the fact, that the code is rather messy imo.
--
Sent via pgsql
what can't be purchased and silenced, should be killed with rain of law suits.
Microsoft does it, novell does it, sco does it, and oracle too.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
So,
after successful, and helpful Saturday with llvm's clang static
checker, I decided to run it against postgresql's source code.
Result can be seen at: http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/
.
One directory below is the tar file, with the report.
I am sure
On 23 Aug 2009, at 17:41, Greg Stark wrote:
On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
I am sure there's plenty of false positives, but I am also quite sure
there's many real errors on that list.
Do you know how to teach clang about functions which
On 23 Aug 2009, at 17:41, Greg Stark wrote:
Do you know how to teach clang about functions which never return?
http://clang-analyzer.llvm.org/annotations.html#attr_noreturn
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
for a very positive one - at least from strict language point of view.
consider: float f = 1; f++; printf(%f\n, f);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
about the false positives around 'null reference'. I'll try sticking
exit(1)'s at the end of each macro - and see if that makes most of
them go away.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
memory leak:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-46wcmJ.html#EndPath
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this one should contain substantialy less false positives, because
error functions were marked as the 'never exit' points:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-9/
for the record, here's patch that marks elog, etc as dead ends:
Index: src/include/utils/elog.h
On 23 Aug 2009, at 20:31, Tom Lane wrote:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
for the record, here's patch that marks elog, etc as dead ends:
That does not look like the right thing at all, since now the checker
will believe that elog(NOTICE) and such don't return. I think
ok folks, here's the last one for Today:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/
tar ball with report can be downloaded from here: http://zlew.org/postgresql_static_check/postgresql_static_check_23rdAugust2009.tar.xz
(compressed with lzma's xz tool).
here's the
On 24 Aug 2009, at 00:15, Greg Stark wrote:
On Sun, Aug 23, 2009 at 11:16 PM, Grzegorz
Jaskiewiczg...@pointblue.com.pl wrote:
ok folks, here's the last one for Today:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/
This does look better. The first one I looked at looks
On 24 Aug 2009, at 14:40, Peter Eisentraut wrote:
On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote:
--enable-cassert, enabled, and also added exit_* in pg_dump to list
of functions that never return.
A few more functions to mark noreturn: DateTimeParseError(), and
die_horribly
On 27 Aug 2009, at 10:46, Paul Matthews wrote:
Grzegorz Jaskiewicz wonderful static checker coughed up 5 errors in
geo_ops.c. None of them of any particular excitement or of earth
shattering nature. A patch is attached below that should correct
these.
(The more little issue we eliminate
heh, sorry folks for the noise again :/
There was a fair amount of false positives there - due to nature of
Assert() macro. Mainly, since assert_enabled is a runtime variable,
not a macro (which I sadly overlooked).
So, hardcoding it to (1) (using CPP) removed quite few false positives.
new one at http://zlew.org/postgresql_static_check/scan-build-2009-08-29-3/
archive at :
http://zlew.org/postgresql_static_check/postgresql_static_check_29thAugust2009.tar.xz
as always, comments are welcomed. And constructive explanation of any
wrong-results will be relayed to clang-checker
On 29 Aug 2009, at 17:35, Greg Stark wrote:
We still have things like this showing division by zero:
Assert(activeTapes 0);
1913 slotsPerTape = (state-memtupsize - state-mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never returning
then it should
On 29 Aug 2009, at 18:05, Greg Stark wrote:
Oh, I think I see what's happening. Our assertions can still be turned
off at run-time with the variable assert_enabled.
Index: src/include/postgres.h
===
RCS file:
okay, I think I nailed the assert part right. (3rd iteration, about
time...).
as usual: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-2/
archive one dir up.
the current patch attached.
postgres_checker_patch.patch.bz2
Description: BZip2 compressed data
--
Sent via
On 30 Aug 2009, at 15:46, Greg Stark wrote:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
well, all I can do is this: http://llvm.org/bugs/show_bug.cgi?id=4832
I find it hard to belive
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 30 Aug 2009, at 18:07, Greg Stark wrote:
On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
Argh. That didn't help at all. hm, I suppose instead
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
please don't tell me that this is bogus: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
?
How come ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 30 Aug 2009, at 19:14, Tom Lane wrote:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
please don't tell me that this is bogus:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
Yes, it's bogus. ctid is never passed as NULL. It might point
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2 Sep 2009, at 21:38, Alvaro Herrera wrote:
Grzegorz Jaskiewicz escribió:
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
What's with the analyzer failures? Did you submit bug reports about
clang developers were quick to iron out their bugs, here's Today report:
http://zlew.org/postgresql_static_check/scan-build-2009-09-04-1/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
usual round of updates to the scan report.
Today's report available at:
http://zlew.org/postgresql_static_check/scan-build-2009-09-12-1/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 14 Sep 2009, at 06:04, Tom Lane wrote:
Looks like the clang guys still have some work to do.
Thanks Tom, reported to clang dev's .
meanwhile, since quite a lot stuff went in over weekend, and since
Yesterday, new report at:
Anyone knows what's the latest on that patch ?
To be honest, this was the thing that I was looking forward most in
8.5 ... (and probably not only me alone).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://llvm.org/bugs/show_bug.cgi?id=4979
will see, one issue is already fixed. I'll retry when the second one
is too.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via
new version under:
http://zlew.org/postgresql_static_check/scan-build-2009-10-03-1/
What's strange, is the increase of 48.2 percent in reports, that
happened about two weeks before (weekend before the previous one).
enjoy.
--
Sent via pgsql-hackers mailing list
On 24 Oct 2009, at 14:41, Magnus Hagander wrote:
Per discussion at the developer meeting back in Ottawa, attached is an
initial patch that implements reading a directory of configuration
files instead of just one. The idea being that something like a tuning
tool, or pgadmin, for example can
On 29 Oct 2009, at 02:15, Itagaki Takahiro wrote:
I'd like to improve partitioning feature in 8.5.
Kedar-san's previous work is wonderful, but I cannot see any updated
patch.
http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com
So, I'll take
consistently fails when compiled on ubuntu 9.10 here (on mini 10v).
regression.diffs.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 13 Nov 2009, at 19:39, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On fre, 2009-11-13 at 15:05 +0100, Grzegorz Jaśkiewicz wrote:
As per Tom's - yes, this laptop has LANG set to UTF8 Polish. Setting
it back to EN actually makes this error go away.
The Polish locale isn't
tell why the first query won't work (subquery is not
allowed as limit's argument, why?).
cheers.
--
Grzegorz Jaskiewicz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http
any news on that front ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2008-12-13, at 13:07, Markus Wanner wrote:
However, that is a marketing decision [1], which should not be mixed
with the technical discussion here. Speaking of a synchronous commit
is utterly misleading, because the commit itself is exactly the thing
that's *not* synchronous.
[1]: Some
On 2008-12-13, at 16:19, Tom Lane wrote:
I'm sure it's technically possible, but I see no redeeming social
value
in it ... we should pick one and quit repainting the bike shed.
+1000
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2008-12-16, at 07:58, ITAGAKI Takahiro wrote:
server says INSERT 0 row though rows are inserted into child
tables.
Technically this is correct since 0 rows were inserted in the parent
table.
Yes, but users expect non-0 result normally. Some O/R mapping tools
also checks the result
create table a(a int not null);
insert into a(a) select generate_series(1,600);
create table b as select * from a where a%10 0;
create index fooa on a(a);
alter table b alter column a set not null;
create index foob on b(a);
vacuum analyze verbose;
gj=# explain select a.a from a where a
all I know, is that the same query will work on 8.3 in reasonably
acceptable time frame.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
true, but as soon as I drop indices on both tables:
root=# explain analyze select a.a from a where a not in (select a from
b);
QUERY PLAN
and the plan on 8.4:
gj=# explain select a.a from a where a not in (select a from b);
QUERY PLAN
-
Seq Scan on a (cost=99035.00..257874197565.00 rows=300 width=4)
Filter: (NOT
On 2008-12-19, at 13:07, Tom Lane wrote:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
Filter: (NOT (hashed subplan))
^^
If 8.3 does that, and 8.4 doesn't, it's most likely because you are
using different work_mem settings.
you're right, as always :)
My point
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw and we just have to live with it.
--
Sent via pgsql-hackers mailing
On 2008-12-22, at 21:07, Bruce Momjian wrote:
Grzegorz Jaskiewicz wrote:
Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw
On 2008-12-22, at 22:35, Dawid Kuroczko wrote:
atlantis= CREATE OR REPLACE FUNCTION foo_trigger() RETURNS trigger AS
$$ BEGIN UPDATE bar SET t=NEW.t WHERE i=NEW.i; RETURN NULL; END; $$
LANGUAGE plpgsql;
atlantis= CREATE TRIGGER foo_update BEFORE UPDATE ON foo FOR EACH ROW
EXECUTE PROCEDURE
WITH RECURSIVE tree(b, l, lv) AS
(
(
WITH RECURSIVE t(b, l) AS
(
select b/11.6, 0 AS l from (select
generate_series(0,30)::float8 b union all select generate_series(30,0,
-1)::float8 b) ziew
UNION ALL
select (b*1.06), l+1 FROM t WHERE l 3
)
select b, l,
On 2009-01-12, at 16:48, Dave Page wrote:
On Mon, Jan 12, 2009 at 4:37 PM, Joshua D. Drake
j...@commandprompt.com wrote:
On Mon, 2009-01-12 at 11:18 -0500, Tom Lane wrote:
Basically I think we are up against the same type of project
management
decision we've had several times before: are
On 2009-01-18, at 09:56, Peter Eisentraut wrote:
On Sunday 18 January 2009 08:28:51 Tom Lane wrote:
Yeah, the risk this is trying to guard against is variables
containing
% unexpectedly. Even if that's not possible, it requires some work
to verify and it's a bit fragile. I didn't look at
On 2009-01-24, at 15:33, Bruce Momjian wrote:
The PostgreSQL community is considering including security
enhancements
in Postgres 8.4, e.g. row-level permissions and SE-Linux security.
However, to evaluate the patch and its usefulness, we need security
experts who want to use this
1 - 100 of 180 matches
Mail list logo
