> The searches are designed so that you can do sub-section searches ... ie.
> if you only wanted to search hackers, the LIKE would be:
>
> 'http://archives.postgresql.org/pgsql-hackers/%%'
>
> while:
>
> 'http://archives.postgresql.org/%%'
>
> would give you a search of *all* the mailing lists
On Thu, 1 Jan 2004, Marc G. Fournier wrote:
> On Thu, 1 Jan 2004, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > 186_archives=# \d ndict7
> > > Table "public.ndict7"
> > > Column | Type | Modifiers
> > > -+-+
> > > url_id | integer
Note that I haven't made many changes to the postgresql.conf file, so
there might be something really obvious I've overlooked, but here are the
uncommented ones (ie. ones I've modified from defaults):
tcpip_socket = true
max_connections = 512
shared_buffers = 1 # min 16, at least max_
On Thu, 1 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I take it there is no way of drop'ng OIDs after the fact, eh? :)
>
> I think we have an ALTER TABLE DROP OIDS command, but it won't instantly
> remove the OIDS from the table --- removal happens incrementally
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I take it there is no way of drop'ng OIDs after the fact, eh? :)
I think we have an ALTER TABLE DROP OIDS command, but it won't instantly
remove the OIDS from the table --- removal happens incrementally as rows
get updated. Maybe that's good enough
On Thu, 1 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I'm still loading the 'WITHOUT OIDS' database ... should I expect that,
> > with CLUSTERing, its performance would be slightly better yet, or would
> > the difference be negligible?
>
> I think the difference
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'm still loading the 'WITHOUT OIDS' database ... should I expect that,
> with CLUSTERing, its performance would be slightly better yet, or would
> the difference be negligible?
I think the difference will be marginal, but worth doing; you're
reduci
On Thu, 1 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Thu, 1 Jan 2004, Tom Lane wrote:
> >> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >>> what sort of impact does CLUSTER have on the system? For instance, an
> >>> index happens nightly, so I'm guessing
On Thu, 1 Jan 2004, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > 186_archives=# \d ndict7
> > Table "public.ndict7"
> > Column | Type | Modifiers
> > -+-+
> > url_id | integer | not null default 0
> > word_id | integer | not null defau
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'k, and for todays question ... how does one 'knock up the stats target'?
ALTER TABLE [ ONLY ] name [ * ]
ALTER [ COLUMN ] column SET STATISTICS integer
The default is 10; try 100, or even 1000 (don't think it will let you
go higher than 1000).
On Thu, 1 Jan 2004, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > Might be worth trying a larger statistics target (say 100), in the hope
> > that the planner then has better information to work with.
>
> I concur with that suggestion. Looking at Marc's problem:
>
>
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Might be worth trying a larger statistics target (say 100), in the hope
> that the planner then has better information to work with.
I concur with that suggestion. Looking at Marc's problem:
On Thu, 1 Jan 2004, Arjen van der Meijden wrote:
> Marc G. Fournier wrote:
> >
> > Now, if I knock off the LIKE, so that I'm returning all rows from ndict8,
> > join'd to all the URLs that contain them, you get:
>
> Can't you build seperate databases for each domain you want to index?
> Than you w
Marc G. Fournier wrote:
Now, if I knock off the LIKE, so that I'm returning all rows from ndict8,
join'd to all the URLs that contain them, you get:
Can't you build seperate databases for each domain you want to index?
Than you wouldn't need the like operator at all.
The like-operator doesn't see
Might be worth trying a larger statistics target (say 100), in the hope
that the planner then has better information to work with.
best wishes
Mark
Marc G. Fournier wrote:
he problem is that right now, we look at the LIKE first, giving us ~300k
rows, and then search through those for those who
On Thu, 1 Jan 2004, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > 186_archives=# \d ndict7
> > Table "public.ndict7"
> > Column | Type | Modifiers
> > -+-+
> > url_id | integer | not null default 0
> > word_id | integer | not null defau
Marc G. Fournier wrote:
> 186_archives=# \d ndict7
> Table "public.ndict7"
> Column | Type | Modifiers
> -+-+
> url_id | integer | not null default 0
> word_id | integer | not null default 0
> intag | integer | not null default 0
> Indexes
On Wed, 31 Dec 2003, Dave Cramer wrote:
> What is the locale of the database?
>
> like won't use an index, unless it is 'C' locale, or you use 7.4 and
> change the operator of the index.
one thing I failed to note ... this is all running on 7.4 ... under 7.3,
it was much much worse :)
Marc
What is the locale of the database?
like won't use an index, unless it is 'C' locale, or you use 7.4 and
change the operator of the index.
Dave
On Wed, 2003-12-31 at 20:49, Marc G. Fournier wrote:
> On Wed, 31 Dec 2003, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Wed, 31 Dec 2003
On Wed, 31 Dec 2003, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Wed, 31 Dec 2003, Bruce Momjian wrote:
> >
> > > > Out of everything I've found so far, mnogosearch is one of the best ... I
> > > > just wish I could figure out where the bottleneck for it was, since, from
> > > > reading
20 matches
Mail list logo
