Hi,
as the wishlist for PostgreSQL 8.4 still has my
IDENTITY/GENERATED patches, I thought I refresh it.
Before actually doing it though, I wanted to ask for opinions
on implementation and ideas.
Here are the general ideas that were done by my patch:
1. IDENTITY columns.
The IDENTITY columns
All,
I am trying to build 8.2.5, forcing to a 32 bit build on a 64 bit
system. I have set CFLAGS=-m32, and I run the configure and make/make
install as follows:
setarch i386 ./configure
setarch i386 make
setarch i386 make install
However, I get the following error (using timezone for example):
Hello,
I am trying to install postgresql-8.2.4 on (Remote Server) with Windows
Server 2003 (pack 1).
I use the postgresql-8.2.msi installer with:
- national language support, PL/java, Development files selected
- install a service option checked with postgres user
- initialize database
Hello,
I am trying to install postgresql-8.2.4 on (Remote Server) with Windows
Server 2003 (pack 1).
I use the postgresql-8.2.msi installer with:
- national language support, PL/java, Development files selected
- install a service option checked with postgres user
- initialize database
I'm not sure, but maybe linker also needs a switch to make 32bit output.
Zdenek
Doug Knight napsal(a):
All,
I am trying to build 8.2.5, forcing to a 32 bit build on a 64 bit
system. I have set CFLAGS=-m32, and I run the configure and make/make
install as follows:
setarch
Doug Knight wrote:
All,
I am trying to build 8.2.5, forcing to a 32 bit build on a 64 bit
system. I have set CFLAGS=-m32, and I run the configure and make/make
install as follows:
setarch i386 ./configure
setarch i386 make
setarch i386 make install
However, I get the following error
Thanks Andrew, I missed the little -o in front of the SUBSYS.o. I did
find that if I did export LDEMULATION=elf_i386 I was able to link
successfully. Now I just need to tell configure that I want to use the
32 bit perl libs, not the 64 bit ones it keeps finding by using:
$PERL -MConfig -e 'print
Pattu, Susanta Kumar wrote:
Hello,
I am trying to install postgresql-8.2.4 on (Remote Server) with
Windows Server 2003 (pack 1).
I use the postgresql-8.2.msi installer with:
- national language support, PL/java, Development files selected
- install a service option checked with postgres
Christian Robottom Reis wrote:
I'm running a conversion of PostgreSQL's CVS repository, but I'm
stuck on a revision that cscvs fails to parse. The hint that the error
gives me is:
Parser error: failed to parse revision data line (line: 'date: 2000/12/04
01:20:38; author: tgl; state:
Doug Knight [EMAIL PROTECTED] writes:
I am trying to build 8.2.5, forcing to a 32 bit build on a 64 bit
system. I have set CFLAGS=-m32,
setarch might help ...
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget
Doug Knight írta:
All,
I am trying to build 8.2.5, forcing to a 32 bit build on a 64 bit
system. I have set CFLAGS=-m32, and I run the configure and make/make
install as follows:
setarch i386 ./configure
setarch i386 make
setarch i386 make install
However, I get the following error (using
Question: We have recently moved PostgreSql as we just migrated to
OpenMfg. i really like the database and PL/pgSQL its very similar to
how FoxPro language layout so learning has been pretty easy.
Now for my question It does not appear PostgreSQL does not have an Ad
Hoc Indexes ability
Justin wrote:
Now for my question It does not appear PostgreSQL does not have an Ad
Hoc Indexes ability where the Query planner will create an in memory
index based on the Select, Update, Insert or Delete commands.
How is that supposed to work? In order to create an index you would need to
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
as the wishlist for PostgreSQL 8.4 still has my
IDENTITY/GENERATED patches, I thought I refresh it.
Before actually doing it though, I wanted to ask for opinions
on implementation and ideas.
IIRC the end conclusion on that patch was that it was
On Feb 18, 2008, at 9:09 PM, Peter Eisentraut wrote:
Justin wrote:
Now for my question It does not appear PostgreSQL does not have an Ad
Hoc Indexes ability where the Query planner will create an in memory
index based on the Select, Update, Insert or Delete commands.
How is that supposed to
Justin [EMAIL PROTECTED] writes:
Is there any plans in the future to add the ability for PostgreSQL to
create Ad Hoc indexes if it makes sense.
No, I'm not aware of anyone contemplating such a thing. I can hardly
imagine a situation where building an index for a single query is
actually a
Alexey Nalbat [EMAIL PROTECTED] writes:
create table t1 ( id integer primary key, name text );
create table t2 ( id integer references t1 );
insert into t1 values ( 1 );
insert into t2 values ( 1 );
Then two concurrent transactions start.
/* 1 */ begin;
/* 1 */ truncate t2;
/* 2
The idea of ad hoc indexes is speed up loop scans To prove my idea i
created a sql file in PGAdmin that creates the indexes on the fly then
runs the query then drops the indexs.
without the indexes it takes 18 to 19 seconds to run the query.
To create the index and do the query takes 400
On Sun, 17 Feb 2008, Christian Robottom Reis wrote:
Ah, interesting. Do you have a URL for the Subversion conversion? Is it
a mirror of CVS, and if so, how often is it updated?
The Subversion one is at
https://projects.commandprompt.com/public/pgsql/repo/ and I haven't
noticed comments on
On Mon, 18 Feb 2008, Tom Lane wrote:
Alexey Nalbat [EMAIL PROTECTED] writes:
create table t1 ( id integer primary key, name text );
create table t2 ( id integer references t1 );
insert into t1 values ( 1 );
insert into t2 values ( 1 );
Then two concurrent transactions start.
/* 1
Hans-Juergen Schoenig wrote:
this kind of indexing makes sense if you visit the same data over and
over again. WITH-queries would be an example for that and self joins
could benefit from the this feature too.
Yes, for joins it is useful. We have hash joins, which are kind of ad hoc
hash
Justin [EMAIL PROTECTED] writes:
The idea of ad hoc indexes is speed up loop scans To prove my idea i
created a sql file in PGAdmin that creates the indexes on the fly then
runs the query then drops the indexs.
without the indexes it takes 18 to 19 seconds to run the query.
To create
Then why are the estimates so far off??? If estimates where correct
would it improve the performance that much.
Vaccum is set to run automatically so the stats stay update.
Total record count for the tables for all the tables put together is
around 120,000 the query returns only 458 records
oops dam spell checker really should be rarely sorry
Justin wrote:
Then why are the estimates so far off??? If estimates where correct
would it improve the performance that much.
Vaccum is set to run automatically so the stats stay update.
Total record count for the tables for all the
Stephan Szabo [EMAIL PROTECTED] writes:
On Mon, 18 Feb 2008, Tom Lane wrote:
but right offhand I see no reason for it to do so --- it doesn't
*do* anything with fk_rel except close it again. Likewise
RI_FKey_keyequal_upd_fk doesn't seem to really need to touch the
pk_rel. Is there something
There seems to have been a bit of a brain cramp upstream :-(.
Previously, AC_FUNC_FSEEKO did this to test if fseeko was available:
return !fseeko;
Now it does this:
return fseeko (stdin, 0, 0) (fseeko) (stdin, 0, 0);
Unfortunately, that gives the compiler enough of a syntactic
Justin wrote:
Then why are the estimates so far off?
Perhaps a really high correlation between those records where coitem_status =
'O' and those records in your date range. The planner estimates 1 row when
restricting by both restrictions, whereas there where 458. The 1 row was
probably a
yes that improved the select statement allot from 18 to 20 to 6
seconds 3 fold improvement with no indexes. thanks
Now i tested your new and improved select statement with the indexes its
query time was taking from 90 to 140 milliseconds compared to the
original select statement of 94 to
Bruce Momjian [EMAIL PROTECTED] writes:
I am not sure this explains the BSD case. NetBSD/BSDi uses
fsetpos/fgetpos to implement fseeko/ftello.
What exactly do you mean by uses --- are fseeko and ftello declared
as macros that call the other two, or what?
I'd kinda have thought that the new
Tom Lane wrote:
There seems to have been a bit of a brain cramp upstream :-(.
Previously, AC_FUNC_FSEEKO did this to test if fseeko was available:
return !fseeko;
Now it does this:
return fseeko (stdin, 0, 0) (fseeko) (stdin, 0, 0);
Unfortunately, that gives the compiler
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am not sure this explains the BSD case. NetBSD/BSDi uses
fsetpos/fgetpos to implement fseeko/ftello.
What exactly do you mean by uses --- are fseeko and ftello declared
as macros that call the other two, or what?
There are
Bruce Momjian [EMAIL PROTECTED] writes:
Have you see these lines lower in configure.in?
if test $ac_cv_func_fseeko = yes; then
AC_SYS_LARGEFILE
fi
Is this broken too?
Yeah, I thought so at first, but looking closer I think it's not too
relevant to the problem. This is
Justin wrote:
although in both case with and with out indexes the estimate still failed to
return the correct number by allot.
The improvement wasn't to the part of the query that had the bad cost estimate,
it was to the part that was being performed hundreds of times instead of the
one
Stephen Denne [EMAIL PROTECTED] writes:
The improvement wasn't to the part of the query that had the bad cost
estimate, it was to the part that was being performed hundreds of times
instead of the one time the planner estimated.
The planner still thought it was only going to perform a
there are certainly problems with this idea. Figuring out the cost to
either create an index or just do table scan would be pain but not
impossible. The hit to index a table in memory i don't think would be
that bad compare to do 100's to thousands of loops with table scans.
I see more
On Mon, 18 Feb 2008, Tom Lane wrote:
There seems to have been a bit of a brain cramp upstream :-(.
Previously, AC_FUNC_FSEEKO did this to test if fseeko was available:
return !fseeko;
Now it does this:
return fseeko (stdin, 0, 0) (fseeko) (stdin, 0, 0);
Unfortunately, that
Richard Huxton wrote:
It would be nice to have a more dynamic language built-in. I'm not
aware of any BSD-licensed dynamic languages though.
Lua is MIT. And I believe there's even a pl/Lua around. The small size
of the interpreter and ease of C interfacing
would make it ideal, or at least
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
as the wishlist for PostgreSQL 8.4 still has my
IDENTITY/GENERATED patches, I thought I refresh it.
Before actually doing it though, I wanted to ask for opinions
on implementation and ideas.
IIRC the end conclusion on that
Tom Lane [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
In my workload, ANALYZE takes long time (1min at statistics_target = 10,
and 5min at 100), but the updated table needs to be vacuumed every 30
seconds
because seqscans run on the table repeatedly.
There is
39 matches
Mail list logo
