A couple of days ago I found myself wanting to aggregate 3 Billion
tuples down to 100 Million tuples based on an integer key with six
integer values -- six sum()'s.
PostgreSQL ran out of memory with its Hash Aggregator and doing an old
style Sort & Sum took a fair amount of time to complete (cance
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What's confusing me at the moment is that it seems to work for Magnus.
> Also, he might be working from a later toolset - I have gcc3.2.4 while
> gcc 3.4.2 is the latest mingw release - some other tools might also be
> mildly out of
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
either.
I wouldn't expect it to handle everything that might appear in LDFLAGS,
but maybe it ought to be given the -L items from LDFLAGS (compare the
way
On Mon, 16 Jan 2006, Anjan Kumar. A. wrote:
>
>
>
> Please observe the following queries. Why PostgreSQL is favouring MergeJoin
> eventhough, it leading to higher execution times than NestedLoopJoin. Any
> suggestions to fix this problem.
>
>
> bench=# EXPLAIN ANALYZE SELECT * FROM tenk1 t1, ten
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> dllwrap doesn't seem to get given LDFLAGS, and maybe doesn't honor it
> either.
I wouldn't expect it to handle everything that might appear in LDFLAGS,
but maybe it ought to be given the -L items from LDFLAGS (compare the
way we copy just those items i
Please observe the following queries. Why PostgreSQL is favouring MergeJoin
eventhough, it leading to higher execution times than NestedLoopJoin. Any
suggestions to fix this problem.
bench=# EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
AND t1.unique2 = t2.unique2;
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
So we should probably change $(DESTDIR)$(bindir) to $(libdir) in the
following places:
For the cygwin/win32 cases, shouldn't we just remove the -L flag from
BE_DLLLIBS altogether? It seems redundant given what Makefile.glob
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> So we should probably change $(DESTDIR)$(bindir) to $(libdir) in the
> following places:
For the cygwin/win32 cases, shouldn't we just remove the -L flag from
BE_DLLLIBS altogether? It seems redundant given what Makefile.global
is doing.
In the Darwi
There's one nontrivial decision still to make about how to implement
proper per-spec row-comparison operations, namely: how a row
comparison ought to be represented in the index access method API.
The current representation of index conditions in the AM API is an
array of ScanKey structs, one per "
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I doubt DESTDIR is having an effect. From what I can see we hardly use
it so it will mostly be blank:
Yes, it is often an empty string, which doubtless explains how an error
of this sort could sneak in. But I think there's
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I doubt DESTDIR is having an effect. From what I can see we hardly use
> it so it will mostly be blank:
Yes, it is often an empty string, which doubtless explains how an error
of this sort could sneak in. But I think there's no doubt that one or
the o
Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
As you see, it adds both bin and lib.
Is the bin part even necessary?
It looks to me like the -L for libdir is coming from Makefile.global.in:
# add location of libpgport.a to LDFLAGS
ifdef PGXS
override LDFLAGS := -L$(
> I asked this question about a half year ago or so, and got:
>
> http://archives.postgresql.org/pgsql-hackers/2005-05/msg00331.php
Thanks James, that's just what I was looking for.
-- Korry
---(end of broadcast)---
TIP
Tom Lane wrote:
In general you are supposed to use the same compiler as the installation
was built with. We are not going to try to support other cases ---
CFLAGS are barely the tip of the iceberg of the issues that would arise.
Right down to the version? I kno
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> As you see, it adds both bin and lib.
Is the bin part even necessary?
It looks to me like the -L for libdir is coming from Makefile.global.in:
# add location of libpgport.a to LDFLAGS
ifdef PGXS
override LDFLAGS := -L$(libdir) $(LDFLAGS)
else
overr
Magnus Hagander wrote:
However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
$(DESTDIR)/$(libdir) and when I make that change in the installed
makefile my module builds happily.
My question is: if I make this change will anything else break?
Offhand that seems like it m
> > However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
> > $(DESTDIR)/$(libdir) and when I make that change in the installed
> > makefile my module builds happily.
>
> > My question is: if I make this change will anything else break?
>
> Offhand that seems like it may just be a think
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> However, libpostgres.a isn't in $(DESTDIR)/$(bindir), it's in
> $(DESTDIR)/$(libdir) and when I make that change in the installed
> makefile my module builds happily.
> My question is: if I make this change will anything else break?
Offhand that see
On Sun, 2006-01-15 at 11:14 -0500, korry wrote:
> (sorry if this has been covered before - if you can point me to a document
> that covers the information I'm looking for, that would be very helpful).
I asked this question about a half year ago or so, and got:
http://archives.postgresql.org/
SOme time ago I wrote:
... seems to be behaving oddly:
dllwrap -o rainbow.dll --def rainbow.def rainbow.o
c:/PROGRA~1/POSTGR~1/8.1/lib/pgxs/src/MAKEFI~1/../../src/utils/dllinit.o
-Lc:/PROGRA~1/POSTGR~1/8.1/bin -lpostgres
c:\mingw\bin\..\lib\gcc-lib\mingw32\3.2.3\..\..\..\..\mingw32\bin\ld.exe:
I've noticed a variety of coding styles in the PostgreSQL source code. In
particular, I see a mix of naming conventions. Some variables use camelCase
(or CamelCase), others use under_score_style.
I'm just wondering if there's a preferred naming convention. Is there an
official convention? A
21 matches
Mail list logo
