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.
>
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 p
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);
>
> Unfortuna
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 i
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 opti
"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
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. Th
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
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 ti
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 n
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 1
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 t
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 res
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 syntacti
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 table
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
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
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
has
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 sta
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 cre
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 mill
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 ho
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
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
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 wa
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
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;
>
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 where
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 ti
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 for
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; s
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 u
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 (using
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 i38
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 cluste
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):
$
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 ar
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 cluste
39 matches
Mail list logo