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 you
* 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 four octets, no?
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 really
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 ;-). My
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
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 ;-)
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 ---
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
FROM
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
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?
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 ;-)
regards,
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,
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.
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 altogether, as
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 using the index,
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 getting
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
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'. ;-}
Except, if we
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 you don't
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 help
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 help
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 performance
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
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
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
* 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 on all the
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 least
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 on
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)
30 matches
Mail list logo
