> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Well, I think it would be helpful to catch the most obvious things
> > people forget, but if no one thinks its a good idea, I will yank it.
>
> If you've got an idea *how* to do it in any sort of reliable fashion,
> I'm all ears. But it sounds more
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, I think it would be helpful to catch the most obvious things
> people forget, but if no one thinks its a good idea, I will yank it.
If you've got an idea *how* to do it in any sort of reliable fashion,
I'm all ears. But it sounds more like pie-in
> so, we are gonna have an AI built into the database now too? my
> experience to date is that each scenario is different for what can be done
> to fix something ... as my last problem shows. I could remove the index,
> since it isn't used anywhere else that I'm aware of, or, as philip pointed
>
On Sun, 5 Nov 2000, Bruce Momjian wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I am adding a new TODO item:
> > > * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
> > > ANALYZE, and CLUSTER
> > > Seems we should be able to emit NOTICE messages suggesting perf
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am adding a new TODO item:
> > * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
> > ANALYZE, and CLUSTER
> > Seems we should be able to emit NOTICE messages suggesting performance
> > improvements.
>
> This would be tar
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am adding a new TODO item:
> * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
> ANALYZE, and CLUSTER
> Seems we should be able to emit NOTICE messages suggesting performance
> improvements.
This would be targeted to hel
I am adding a new TODO item:
* Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
ANALYZE, and CLUSTER
Seems we should be able to emit NOTICE messages suggesting performance
improvements.
> Philip Warner <[EMAIL PROTECTED]> writes:
> > Could you trick it into n
On Mon, 6 Nov 2000, Philip Warner wrote:
> At 23:12 5/11/00 -0400, The Hermit Hacker wrote:
> >
> >Except, if we are telling it to get rid of using the index, may as well
> >get rid of it altogether, as updates/inserts would be slowed down by
> >having to update that too ...
> >
>
> So long as y
On Sun, 5 Nov 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > On Mon, 6 Nov 2000, Philip Warner wrote:
> >> At 21:59 5/11/00 -0500, Tom Lane wrote:
> Looks like a great kluge to me ;-)
> >>
> >> Hmph. I prefer to think of it as a 'user-defined optimizer hint'. ;-}
The Hermit Hacker wrote:
> I'm tryin to figure out how to speed up udmsearch when run under
> postgresql, and am being hit by atrocious performance when using a LIKE
> query ... the query looks like:
> SELECT ndict.url_id,ndict.intag
> FROM ndict,url
> WHERE ndict.word_id=1971739852
>AND ur
At 23:12 5/11/00 -0400, The Hermit Hacker wrote:
>
>Except, if we are telling it to get rid of using the index, may as well
>get rid of it altogether, as updates/inserts would be slowed down by
>having to update that too ...
>
So long as you don't ever need the index for anything else, then getti
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> On Mon, 6 Nov 2000, Philip Warner wrote:
>> At 21:59 5/11/00 -0500, Tom Lane wrote:
Looks like a great kluge to me ;-)
>>
>> Hmph. I prefer to think of it as a 'user-defined optimizer hint'. ;-}
> Except, if we are telling it to get rid of usi
On Mon, 6 Nov 2000, Philip Warner wrote:
> At 21:59 5/11/00 -0500, Tom Lane wrote:
> >
> >Looks like a great kluge to me ;-)
> >
>
> Hmph. I prefer to think of it as a 'user-defined optimizer hint'. ;-}
Except, if we are telling it to get rid of using the index, may as well
get rid of it altoge
At 21:59 5/11/00 -0500, Tom Lane wrote:
>
>Looks like a great kluge to me ;-)
>
Hmph. I prefer to think of it as a 'user-defined optimizer hint'. ;-}
Philip Warner| __---_
Albatross Consulting Pty. Ltd.
yowch ... removing that one index makes my 'test' search (mvcc) come back
as:
[97366] SQL 0.05s: SELECT ndict.url_id,ndict.intag FROM ndict,url WHERE
ndict.word_id=572517542 AND url.rec_id=ndict.url_id AND (url.url LIKE
'http://www.postgresql.org/%')
vs what we were doing before ... now, let
Philip Warner <[EMAIL PROTECTED]> writes:
> Could you trick it into not using the index (AND using the other strategy?)
> by using a calculation:
>AND ( (url.url || ' ') LIKE 'http://www.postgresql.org/% ');
> it's a bit nasty.
Looks like a great kluge to me ;-)
reg
Yes, I am waiting to hear back on that.
> At 21:47 5/11/00 -0500, Tom Lane wrote:
> >It's ye same olde nonuniform-distribution
> >problem; until we have better statistics, there's not much hope
> >for a non-kluge solution.
>
> Wasn't somebody trying to do something with that a few weeks back?
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Sorry to be getting in here late. Have you tried CLUSTER?
>
> Prolly won't help much. I think what he's getting burnt by
> is that the planner thinks that an indexscan based on the
> LIKE 'http://www.postgresql.org/%' condition will be extremely
>
At 21:47 5/11/00 -0500, Tom Lane wrote:
>It's ye same olde nonuniform-distribution
>problem; until we have better statistics, there's not much hope
>for a non-kluge solution.
Wasn't somebody trying to do something with that a few weeks back?
-
At 21:28 5/11/00 -0500, Tom Lane wrote:
>A brute-force answer would be to remove the url_url index ;-)
>dunno if that would slow down other queries, however.
Could you trick it into not using the index (AND using the other strategy?)
by using a calculation:
SELECT ndict.url_id,ndict.intag
FRO
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Sorry to be getting in here late. Have you tried CLUSTER?
Prolly won't help much. I think what he's getting burnt by
is that the planner thinks that an indexscan based on the
LIKE 'http://www.postgresql.org/%' condition will be extremely
selective ---
Sorry to be getting in here late. Have you tried CLUSTER? If it is
using an index scan, and it is slow, cluster often helps, especially
when there are several duplicate matches, as there is with LIKE. Let me
know how that works.
> A brute-force answer would be to remove the url_url index ;-)
>
A brute-force answer would be to remove the url_url index ;-)
dunno if that would slow down other queries, however.
regards, tom lane
I'm tryin to figure out how to speed up udmsearch when run under
postgresql, and am being hit by atrocious performance when using a LIKE
query ... the query looks like:
SELECT ndict.url_id,ndict.intag
FROM ndict,url
WHERE ndict.word_id=1971739852
AND url.rec_id=ndict.url_id
AND (ur
> Do you mind if we name this "--enable-unicode-conversion"? It's a bit
> longer, but that's why they're called long options. :)
Sounds reasonable:-) Please go ahead and change it.
--
Tatsuo Ishii
Hi
RelationCacheInvalidate() is called from ResetSystemCaches()
and calles RelationFlushRelation() for all relation descriptors
except some nailed system relations.
I'm wondering why nailed relations could be exceptions.
Conversely why must RelationCacheInvalidate() call
RelationFlushRelation() fo
* Hannu Krosing <[EMAIL PROTECTED]> [001105 15:21]:
> Peter Eisentraut wrote:
> >
> I suspect that we do on many platforms (like *BSD, Linux and Win32).
Many, but not *ALL*. I prefer to build my stuff using the Native
UnixWare 7 (UDK) Compiler. As of the Feature Supplement (due out any
week now
Peter Eisentraut wrote:
>
> Hannu Krosing writes:
>
> > > The first thought that comes to mind is that XIDs should be promoted to
> > > eight bytes. However there are several practical problems with this:
> > > * portability --- I don't believe long long int exists on all the
> > > platforms we
* Tom Lane <[EMAIL PROTECTED]> [001105 12:07]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> >> Uh, we don't want to depend on gcc, do we?
>
> > Doesn't C99 *REQUIRE* long long?
>
> What difference does that make? It'll be a very long time before
> Postgres can REQUIRE that people have a C99-c
Peter,
I've looked at the current implementation of the bit types and still
have some doubts concerning the following issues:
1. Constants. The current behaviour just seems somewhat strange, and I
have no idea where to fix it.
test=# select B'1001';
?column?
--
X9
(1 row)
te
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> Uh, we don't want to depend on gcc, do we?
> Doesn't C99 *REQUIRE* long long?
What difference does that make? It'll be a very long time before
Postgres can REQUIRE that people have a C99-compliant compiler.
Portability does not mean "we work great o
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> * disk space --- letting pg_log grow without bound isn't a pleasant
>> prospect either.
> How will 2x size increase of xid cause "boundless" growth of pg_log ;)
OK, 2^64 isn't mathematically unbounded, but let's see you buy a disk
that will hold it ;-
* Peter Eisentraut <[EMAIL PROTECTED]> [001105 09:39]:
> Hannu Krosing writes:
>
> > > The first thought that comes to mind is that XIDs should be promoted to
> > > eight bytes. However there are several practical problems with this:
> > > * portability --- I don't believe long long int exists o
Hannu Krosing writes:
> > The first thought that comes to mind is that XIDs should be promoted to
> > eight bytes. However there are several practical problems with this:
> > * portability --- I don't believe long long int exists on all the
> > platforms we support.
>
> I suspect that gcc at le
Tom Lane wrote:
>
> We've expended a lot of worry and discussion in the past about what
> happens if the OID generator wraps around. However, there is another
> 4-byte counter in the system: the transaction ID (XID) generator.
> While OID wraparound is survivable, if XIDs wrap around then we rea
* Peter Eisentraut <[EMAIL PROTECTED]> [001105 07:08]:
> Tom Lane writes:
>
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > A separate function for formatting output seems necessary, but
> > > if we don't reach an agreement though, it ought to work to cast
> > > CIDR to INET to get all fou
> One idea I had from this is actually truncating pg_log at some point if
> we know all the tuples have the special committed xid. It would prevent
> the file from growing without bounds.
Not truncating, but implementing pg_log as set of files - we could remove
files for old xids.
> Vadim, can
37 matches
Mail list logo
