Hi,
I'm playing with GIN to make a full text search system. GIN comes with
built-in TEXT[] support and I use string_to_array() to make a
TEXT[]. Problem is, if there's large number of array elemets,
string_to_array() consumes too much memory. For example, to make ~70k
array elements, string_to_arr
Heikki,
On 11/7/06 1:51 AM, "Heikki Linnakangas" <[EMAIL PROTECTED]> wrote:
> I don't think Simon's proposal is meant to address that issue, but did
> you follow the thread I started in September about Block B-Tree index:
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg02041.php
Aha -
On Tue, 2006-11-07 at 17:56 +1100, Brendan Jurd wrote:
> Should be just six extra lines (patch attached, untested).
Applied to HEAD, with an additional fix: you need to clear "result5" as
well. I didn't bother applying it to backbranches, on the grounds that a
memory leak in psql is not serious.
On Sun, Nov 05, 2006 at 11:49:36 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> As already discussed upthread, anyone who wants the path can get it from
> `pwd` or local equivalent --- and that mechanism is robust (as long as
> the directory move doesn't happen while any particular instance of t
I can see that adding null to indexes would allow all cases of "is not
distinct from"
to use them.
The lack of null in indexes would explain why a condition such as "col is
not distinct from null"
would not pick up an index.
But my example was: "col is not distinct from 123"
and the equivalen
On Tue, Nov 07, 2006 at 02:12:29PM -0600, Jim C. Nasby wrote:
> I assume you're referring to
> http://archives.postgresql.org/pgsql-patches/2005-09/msg00083.php ?
>
> I'm curious as to the status of that patch... presumably it never made
> it into the queue, but I'm not sure why since you seemed t
On Tue, Nov 07, 2006 at 11:03:42AM +0100, Martijn van Oosterhout wrote:
> On Mon, Nov 06, 2006 at 09:10:40PM -0500, JEAN-PIERRE PELLETIER wrote:
> > I understand that the planner doesn't use indexes for IS NOT DISTINCT FROM,
> > but it would
> > be good because "is not distinct from" is very usefu
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As a result of there being two *known* outstanding bugs, we have just bundled
up a Beta3, to allow for testing of the recent patch concerning WAL replay ...
Please download the latest beta from:
ftp.postgresql.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As a result of there being two *known* outstanding bugs, we have just bundled
up a Beta3, to allow for testing of the recent patch concerning WAL replay ...
Please download the latest beta from:
ftp.postgresql.org:/pub/source/v8.2beta
While
Luke,
> That's our plan to achieve speedups that other DBMS's have achieved with
> Index-Organized-Tables or Clustered Indexes. We're running initial
> performance tests of it as we speak, and if all goes well we're hoping
> to get that into PostgreSQL 8.3.
Also, if the EDB folks weren't clear, t
Thanks for the references.Note for future: should have tried VACUUM too.On 11/7/06, Tom Lane <[EMAIL PROTECTED]
> wrote:"Gurjeet Singh" <
[EMAIL PROTECTED]> writes:> Please refer the following session snippet. It seems that creating and> dropping an index on a table, within a transaction, leave
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> Please refer the following session snippet. It seems that creating and
> dropping an index on a table, within a transaction, leaves the table marked
> as having an index.
This isn't a bug. Refer to catalogs.sgml:
relhasindex
True if this
Gurjeet Singh wrote:
Hi All,
Please refer the following session snippet. It seems that creating and
dropping an index on a table, within a transaction, leaves the table marked
as having an index. Although, I don't think it's a serious bug, since we
always retrieve the list using RelationGetIn
Hi All, Please refer the following session snippet. It seems that creating and dropping an index on a table, within a transaction, leaves the table marked as having an index. Although, I don't think it's a serious bug, since we always retrieve the list using RelationGetIndexList(), and that list
On Tue, 2006-11-07 at 17:56 +1100, Brendan Jurd wrote:
> It certainly isn't pretty. It's been a long time since I looked down
> the barrel of a 'goto'.
I don't think there's anything wrong with using "goto" for error
handling in this style. Personally, I think the main stylistic problem
is that t
On Mon, Nov 06, 2006 at 09:10:40PM -0500, JEAN-PIERRE PELLETIER wrote:
> I understand that the planner doesn't use indexes for IS NOT DISTINCT FROM,
> but it would
> be good because "is not distinct from" is very useful when you have nulls
> but don't want to use three value logic.
The main issu
Luke Lonergan wrote:
Simon,
Bring it on! We at GP have been evaluating various approaches to index
organized tables which unify index with heap storage to solve some of
the problems you mention. Split index and heap is a big issue in
Postgres and we'd all welcome a good solution to it, even fo
17 matches
Mail list logo
