Gregory Stark <[EMAIL PROTECTED]> writes:
> What if the equivalence class is in more than one place in the ORDER BY?
That's not a problem. ORDER BY 1,1 is not different from ORDER BY 1,
even if the referenced expression is volatile, because the secondary
sort key is useless anyway.
> And what w
Jeff Davis <[EMAIL PROTECTED]> writes:
> I agree that a dump/restore from 8.2 with tsearch2 to 8.3 with built-in
> tsearch should not SIGSEGV.
That's not what he did, though. Force-feeding contrib/tsearch2 into 8.3
will not work.
regards, tom lane
---
Radoslaw Zielinski <[EMAIL PROTECTED]> writes:
> Is contrib/tsearch2 obsolete?
Yes.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Josh Berkus wrote:
Neil Conway wrote:
On Wed, 2007-11-07 at 11:38 +0900, Josh Berkus wrote:
./configure --with-libxml does not accept a location argument. This
makes it impossible to configure 8.3 with LibXML on the Mac, because
I can't upgrade the main libxml without breaking something, an
Neil Conway wrote:
On Wed, 2007-11-07 at 11:38 +0900, Josh Berkus wrote:
./configure --with-libxml does not accept a location argument. This
makes it impossible to configure 8.3 with LibXML on the Mac, because I
can't upgrade the main libxml without breaking something, and
./configure doesn't
On Wed, 2007-11-07 at 11:38 +0900, Josh Berkus wrote:
> ./configure --with-libxml does not accept a location argument. This
> makes it impossible to configure 8.3 with LibXML on the Mac, because I
> can't upgrade the main libxml without breaking something, and
> ./configure doesn't let me speci
Peter, Nickolay,
./configure --with-libxml does not accept a location argument. This
makes it impossible to configure 8.3 with LibXML on the Mac, because I
can't upgrade the main libxml without breaking something, and
./configure doesn't let me specify an alternate location.
--with-libxml s
"Tom Lane" <[EMAIL PROTECTED]> writes:
> select random() as a, random() as b from foo order by b, a;
>
> And it definitely seems the wrong thing for the last one.
Ouch.
> What I'm thinking of doing is adding a field to EquivalenceClass that
> carries the ressortgroupref of the originating
On Tue, 2007-11-06 at 23:00 +, Radoslaw Zielinski wrote:
> Hello,
>
> Beta2 crashes on restoring a dump of tsearch2-enabled database, as
> produced by 8.2.x (x==5 IIRC) pg_dump; the shortest way I know to get
> the SIG11:
Here is a guide to help migrate tsearch2 data from 8.2 to 8.3:
http://
Hello,
Beta2 crashes on restoring a dump of tsearch2-enabled database, as
produced by 8.2.x (x==5 IIRC) pg_dump; the shortest way I know to get
the SIG11:
SET search_path = public, pg_catalog;
CREATE TYPE tsvector;
CREATE FUNCTION tsvector_in(cstring) RETURNS tsvector
AS '$libdir/ts
Hi Robert (small world, I contributed to Sequoia a while ago...), all,
On 11/6/07, Robert Hodges <[EMAIL PROTECTED]> wrote:
> 2.) Test hardware. We have a number of hosts in Grenoble, France that are
> available to help set up a European lab.We gave away 4 to the
> postgresql.fr folks but if
Hello,
Beta2 crashes on restoring a dump of tsearch2-enabled database, as
produced by 8.2.x (x==5 IIRC) pg_dump; the shortest way I know to get
the SIG11:
SET search_path = public, pg_catalog;
CREATE TYPE tsvector;
CREATE FUNCTION tsvector_in(cstring) RETURNS tsvector
AS '$libdir/ts
Hi everyone,
Here are a couple of additions to the performance test lab
discussion. I hope you will find these useful.
1.) Test tools. The Bristlecone testing package I presented at the
PG Fall 2007 Conference is now available at http://
bristlecone.continuent.org. There are two main t
Hello
I am writing tsearch2 wrapper and I testing functionality. I found
some little bit strange on default parser. It can't parse tags with
numbers:
test=# select * from parse('zluty kun se napil zlute vody');
tokid | token
---+---
12 | <
3 | h1
12 | >
1 | zluty
12
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> The clarity stems from the fact that this is the variant that doesn't
> lose data whereas the other one does.
I think double has a wider range. So you get a choice between losing precision
or not being able to store all values.
> The expression
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I don't buy that. I believe at least on some architectures you'd get a
> word-long load+modify+store, and scribble the neighboring bytes.
Hm, I mis-remembered this bit of advice from the glibc info doc. I remembered
thinking it was strange when I
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> For example, if there is a query like select count(1) from table. Then
> we can scan through all the index pages and the visibility map to get
> the count. Currently it goes for Full table scan. there should be
> something like full index
Awhile back there was some discussion about how the system assumes that
syntactically equal sort expressions can be considered interchangeable,
which falls down if volatile functions are involved:
http://archives.postgresql.org/pgsql-general/2006-11/msg01523.php
I seem to recall the issue coming up
Dear Tom,
On Tue, 6 Nov 2007, Tom Lane wrote:
> Date: Tue, 06 Nov 2007 10:05:58 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Heikki Linnakangas <[EMAIL PROTECTED]>,
> Rick Gigger <[EMAIL PROTECTED]>,
> pgsql-hackers list
> Subject: Re: [HACKERS] should I worr
Hi all!
There will be planned downtime on tribble.postgresql.org Nov 7(tomorrow)
from 11:30-12:00 GMT(estimated) affecting the following services:
cvs.postgresql.org
wwwmaster.postgresql.org
www.pgadmin.org
doxygen.postgresql.org
Downtime is necessary to implement several changes to the installe
On Tue, 2007-11-06 at 08:01 -0500, Mark Mielke wrote:
> Simon Riggs wrote:
> > On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> > I'm racking my brain trying to think of a query that will benefit from
> > index-only scans without specifically creating covered indexes. Apart
> > from c
On Tue, 06 Nov 2007 13:15:02 +
Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-11-05 at 14:33 -0800, Mark Wong wrote:
> > On 11/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > >
> > > Why don't you post a TODO list for TPC-E somewhere, so people can bite
> > > small pieces off of the li
On Mon, 2007-11-05 at 22:45 +, Heikki Linnakangas wrote:
> > 1) Do as you say above. What are some of the cost trade-offs here? It
> > seems that frequent VACUUM FREEZE runs would keep the visibility map
> > mostly full, but will also cause more writing. I suppose the worst case
> > is that eve
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > It apparently casts the 1 to double precision to pick the variant
> > trunc(dp)=>dp instead of trunc(numeric)=>numeric. I was under the
> > impression that we didn't want to cast integers to float types
> > implicitly because this
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> pei=# select castsource::regtype, casttarget::regtype, castcontext from
> pg_cast order by 1,2;
> ERROR: XX000: could not find pathkey item to sort
> LOCATION: make_sort_from_pathkeys, createplan.c:2812
Hmph. When we hacked that function last week
"Gevik Babakhani" <[EMAIL PROTECTED]> writes:
> Unfortunately for func.param is this problematic because
> qualifiedNameToVar and transformWholeRowRef/ParseFuncOrColumn
> internally call RTE functions which justifiably throw an "ambiguous column
> error".
What's the problem? If it's ambiguous wi
Hello,
This is about:
http://archives.postgresql.org/pgsql-patches/2007-11/msg00028.php
In order to resolve . the check in
transformColumnRef goes into case 2 which is A.B
The ideal way to resolve the func.param in this case is to perform the
callback (hook)
after ALL the checks (like qualifie
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It apparently casts the 1 to double precision to pick the variant
> trunc(dp)=>dp instead of trunc(numeric)=>numeric. I was under the impression
> that we didn't want to cast integers to float types implicitly because this
> loses information. Clearl
Am Dienstag, 6. November 2007 schrieb Peter Eisentraut:
> I noticed this problem in 8.2 and 8.3:
>
> pei=# select mod( trunc( 1 ), 2 );
> ERROR: 42883: function mod(double precision, integer) does not exist
> LINE 1: select mod( trunc( 1 ), 2 );
>^
>
> It apparently casts the 1 to
--On Dienstag, November 06, 2007 16:31:05 +0100 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
I noticed this problem in 8.2 and 8.3:
pei=# select mod( trunc( 1 ), 2 );
ERROR: 42883: function mod(double precision, integer) does not exist
LINE 1: select mod( trunc( 1 ), 2 );
^
It
By the way, please have a look at how i have converted a index scan
into a index only scan in the thick index patch. Currently it doesn't
convert those queries which doesn't have where clause. I hope you
would be able refine it further.
For example, if there is a query like select count(1) from tab
This used to work in 8.2:
pei=# select castsource::regtype, casttarget::regtype, castcontext from pg_cast
order by 1,2;
But int 8.3 it says:
ERROR: XX000: could not find pathkey item to sort
LOCATION: make_sort_from_pathkeys, createplan.c:2812
--
Peter Eisentraut
http://developer.postgresql
I noticed this problem in 8.2 and 8.3:
pei=# select mod( trunc( 1 ), 2 );
ERROR: 42883: function mod(double precision, integer) does not exist
LINE 1: select mod( trunc( 1 ), 2 );
^
It apparently casts the 1 to double precision to pick the variant
trunc(dp)=>dp instead of trunc(n
[EMAIL PROTECTED] writes:
> IIUC, I have drop every trigger like this :
> SELECT t.tgname, c.relname, tgconstrname FROM pg_trigger t, pg_class c
> WHERE t.tgrelid = c.oid AND tgname like 'RI_ConstraintTrigger_%'AND
> tgconstrname = '';
> and I delete all those ancient foreign key WITHOUT disturbi
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> I'd love to find a query against pg_triggers giving the table name for
>> each RI_ConstraintTrigger_xxx.
> SELECT t.tgname, c.relname, tgconstrname FROM pg_trigger t, pg_class c
> WHERE t.tgrelid = c.oid AND tgname like
Gokulakannan Somasundaram wrote:
On Nov 6, 2007 4:33 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Gokulakannan Somasundaram wrote:
Just one more thought on the same. This implementation also assumes
that there won't be any update chains across pages, which is the
current stage.
No, it doe
On Tue, 6 Nov 2007, Heikki Linnakangas wrote:
> Date: Tue, 06 Nov 2007 13:07:23 +
> From: Heikki Linnakangas <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Tom Lane <[EMAIL PROTECTED]>, Rick Gigger <[EMAIL PROTECTED]>,
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] should I wo
On Nov 6, 2007 4:33 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Gokulakannan Somasundaram wrote:
> > Just one more thought on the same. This implementation also assumes
> > that there won't be any update chains across pages, which is the
> > current stage.
>
> No, it doesn't assume that.
S
Shreya Bhargava <[EMAIL PROTECTED]> writes:
> We performed some probe tests on our patch on
> hash index and the original btree index to compare the
> performance between the two.
Interesting, but ...
> From the results obtained, the average of all the hash probes is 141.8ms, the
> average for
Simon Riggs wrote:
On Tue, 2007-11-06 at 13:29 +, Heikki Linnakangas wrote:
And of course people will start adding columns to indexes, to make use
of index-only-scans, once we have the capability.
Not too keen on that. Very difficult to judge whether its worth the
benefit for creati
Simon Riggs wrote:
I'm thinking that looking in the visibility map will have a cost also,
so how will we know whether to bother looking? I'm assuming that we
won't want to do that lookup in all cases, since it could easily just
add pathlength and contention in the normal OLTP case.
Yeah, I beli
On Tue, 2007-11-06 at 13:29 +, Heikki Linnakangas wrote:
> > My list would be:
> > - EXISTS / NOT EXISTS
> > - COUNT(*)
>
> Yeah, those are good candidates.
Yeah.
> Many-to-many relationships is one example:
OK, thats a very good one.
> And of course people will start adding columns to in
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
One problem is that you have to atomically update the visibility map when
you update the heap. That means that you have to lock the visibility map
page and the heap page at the same time. If the visibility map is in the
heap,
On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Marko Kreen wrote:
> > On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> >> (Gosh, we really need a name for the sort of vacuum. I was about to say
> >> "we'd still need regular regular VACUUMs" :-))
> >
> > As the new VACUUM var
On Mon, 2007-11-05 at 14:33 -0800, Mark Wong wrote:
> On 11/4/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > Why don't you post a TODO list for TPC-E somewhere, so people can bite
> > small pieces off of the list. I'm sure there's lots of people can help
> > if we do it that way.
>
> This shou
Mark Mielke wrote:
Simon Riggs wrote:
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
I'm racking my brain trying to think of a query that will benefit from
index-only scans without specifically creating covered indexes. Apart
from count(*) queries and RI lookups. I can't see RI loo
Marko Kreen wrote:
On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
(Gosh, we really need a name for the sort of vacuum. I was about to say
"we'd still need regular regular VACUUMs" :-))
As the new VACUUM variant will be somewhat unsafe, it should
not replace "regular" VACUUM but get
On 11/6/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Jeff Davis wrote:
> > On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> >> It's not useful for VACUUM FREEZE, unless we're willing to freeze much
> >> more aggressively, and change the meaning of a set bit to "all tuples on
>
On 11/6/07, Mark Mielke <[EMAIL PROTECTED]> wrote:
> Simon Riggs wrote:
> > On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> > I'm racking my brain trying to think of a query that will benefit from
> > index-only scans without specifically creating covered indexes. Apart
> > from coun
On 11/6/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera wrote:
> > > > Tom, how about putting a note about that into next 8.2 minor
> > > > release notes? (8.3 too?) Something like "You need to refresh
> > > > pgcrypto functions, because since rel 8.2 the code depends
> > > > on fun
Mark Mielke wrote:
I'm not sure what RI lookup is. Sorry. :-)
RI = Referential Integrity. i.e. Foreign Keys.
cheers
andrew
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[EMAIL PROTECTED] wrote:
I'd love to find a query against pg_triggers giving the table name for
each RI_ConstraintTrigger_xxx.
SELECT t.tgname, c.relname, tgconstrname FROM pg_trigger t, pg_class c
WHERE t.tgrelid = c.oid AND tgname like 'RI_ConstraintTrigger_%';
--
Heikki Linnakangas
E
Simon Riggs wrote:
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
I'm racking my brain trying to think of a query that will benefit from
index-only scans without specifically creating covered indexes. Apart
from count(*) queries and RI lookups. I can't see RI lookups being much
chea
On Mon, 2007-11-05 at 09:52 +, Heikki Linnakangas wrote:
> Reducing VACUUM time is important, but the real big promise is the
> ability to do index-only-scans.
Have you thought about how index-only scans work work? Seems like we
need a rough plan for that before we go and build the visibili
On Mon, 5 Nov 2007, Tom Lane wrote:
> Date: Mon, 05 Nov 2007 15:53:10 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Heikki Linnakangas <[EMAIL PROTECTED]>
> Cc: Rick Gigger <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] should I worry?
>
> H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shreya Bhargava wrote:
> "Note that the bottom line for the problems with hash indexes is that the
> current implementation doesn't offer any advantages over btree indexes. Hash
> indexes need to be not only as good of a choice as btree indexes but
> s
Gokulakannan Somasundaram wrote:
Just one more thought on the same. This implementation also assumes
that there won't be any update chains across pages, which is the
current stage.
No, it doesn't assume that.
Heikki,
Is it planned as a optional feature? (I support the optional
feature
Shreya Bhargava wrote:
1. Populate the table with 80 million tuples.
2. Create HASH index on the table.
3. clear both linux cache & psql buffers.
(exiting psql and restarting it cleared the psql buffers;
to clear linux cache, we used drop_cache command)
4. start psql
5. select on an intege
I have not followed this thread very closely. But just wanted to give my inputs.
> From the results obtained, the average of all the hash probes is 141.8ms,
> the average for btree is 168.5, a difference of about 27.The standard
> deviations are about 23, so this is a statistically significant di
Just one more thought on the same. This implementation also assumes
that there won't be any update chains across pages, which is the
current stage.
Heikki,
Is it planned as a optional feature? (I support the optional
feature model)
Thanks,
Gokul.
On Nov 6, 2007 12:20 PM, Gregory Stark <[
60 matches
Mail list logo
