Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> How you figure that?
> Well I'm not clear exactly what's going on with the semaphores here. If it's
> possible for to be printing the messages only as a resu
gather this info, random users
shouldn't be able to turn it off.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
ly not producing
the ideal XML structure.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ter
> the deadlock detection.
It's elog(LOG), which you can get on the client if you want. The chance
of making it NOTICE is epsilon...
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Gregory Stark <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> In fact, I am scandalized to see that someone has inserted a boatload
>> of elog calls into CheckDeadLock since 8.2 --- that seems entirely
>> unsafe. [ checks revision history... ]
s there a reason not to do that?
I suppose it would eat a few more cycles ...
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if you
ts if it didn't get the condition it wants. Before, I think we
did that for every use of the semaphore except this one (which is an
outgrowth of the fact that originally this was indeed the only use of
the sema, and the others got shoehorned in over time).
I'll check it ov
y --- if we eliminated that
whole loop and just always queued at the end of the list, we'd still get
the lock, but not till after the deadlock check delay had elapsed.
regards, tom lane
---(end of broadcast)--
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Yeah, my proposed patch is schoolbook division. I don't think I'd trust
>> Newton's method to give anything but a close approximation, which is
>> wha
Newton's method to give anything but a close approximation, which is
what we have in HEAD already.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
the heap. I suggest making RelationGetIndexList() cache
the OID of the clustered index (if any) in relcache entries, and add
RelationGetClusterIndex much like RelationGetOidIndex, and then
heap_insert can use that.
regards, tom lane
---(end of b
ll this is a bit annoying. Anyone see a way to speed it up, or
have another approach?
regards, tom lane
binZ6bTIGGXbC.bin
Description: numeric-div.patch.gz
---(end of broadcast)---
TIP 3: Have you checked
.conf
file without any thought when moving to a new release.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
since it was last
filled up.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I think this patch has no (or small) impact on functionality and it
> should be committed to 8.3
This missed the feature freeze deadline by well over two months.
It is not a candidate for 8.3.
regar
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> [confused...] How do you envision proceeding exactly?
> Never mind, if you're happy adapting and applying this right away to
> back branches then I'm happy too. I just didn't want to have to wai
s, but I'd be happy to wait for the
> back branches in this case.
[confused...] How do you envision proceeding exactly?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ugh test. Maybe
we could get Ed L. or one of the other complainants to try it. (The
patch seems to need some adjustment to apply against 8.2, though.)
regards, tom lane
binVOvljxL6WO.bin
Description: logpipe-2.patch.gz
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Can I not use a StringInfo in the syslogger?
Should work, elog.c expects it will --- I'd wonder about premature pfree
or something like that. Are you testing with --enable-cassert?
reg
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> After looking closer, I think there are worse problems here: the code is
>> still using VARSIZE/VARDATA etc, which it should not be because the
>> field could easily be
ns, seeing that this table's layout seems unlikely
to change. But it seems like we might want to trouble with a null
test. Thoughts?
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the
omments are about. I'm not especially worried about
mechanizing it since in practice code that tries to access those fields
will crash pretty obviously and consistently, except for the first such
field which is safe anyway.
regards, tom lane
Gregory Stark <[EMAIL PROTECTED]> writes:
> Why do we even have those fields in the structs if they're unsafe to use?
1. genbki.sh
2. As you note, they're not always unsafe to use.
regards, tom lane
-
r name until runtime,
it seems that this would work if we allowed a parameter symbol there.
Offhand that doesn't look hard.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore yo
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2007/6/11, Tom Lane <[EMAIL PROTECTED]>:
>> Why do we need this?
>>
> For stored procedures.
No, the question is what is the patch trying to accomplish, because
as far as I can see it's wrong. It seems t
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> this small patch allows using updatable cursors in plpgsql.
Why do we need this?
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the Po
es.
The main stumbling block is cleaning out index entries for the
known-dead heap tuple. The current VACUUM design amortizes that cost
across as many dead heap tuples as it can manage; doing it retail seems
inevitably to be a lot more expensive.
regards, tom lane
--
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> The vacuum-cost-limit issue may be sufficient reason to kill this idea;
>> not sure.
> We already have a much higher cost for blocks that cause i/o than
> blocks w
acuum pass at the
instant where the scan would wrap around, so that the list could be
cleared before putting any lower-numbered blocks into it.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Fri, 2007-06-08 at 12:22 -0400, Tom Lane wrote:
>> Now that I'm awake, it is reachable code, per this comment:
>>
>> * Note: when we fall off the end of the scan in either direction, we
>> * reset rs_inited. This
it. Any
strong feelings one way or the other? AFAIK the only case where
it'd happen is if someone reads forwards in a large-seqscan cursor
for awhile and then reads backwards. You could argue that doing
that is a good reason to drop them out of the syncscan pack ...
he correct fix would be to make ANALYZE
sort the rels by OID, anyhow, not to dumb down the scan.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Jeff Davis <[EMAIL PROTECTED]> writes:
>>> Just to be sure: a backwards-started scan is currently unreachable code,
>>> correct?
>>
>> [ yawn... ] I think so, but I wouldn&#
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It occurs to me that there's an actual bug here for catalog access.
>> The code assumes that it can measure rs_nblocks only once and not worry
>> about tuples added beyond that endpoint. But th
nting a concurrent update). But we ought to
fix it while we're touching the code now. That will take re-measuring
rs_nblocks each time we consider stopping, and I think we definitely
will NOT want the syncscan code getting involved.
I'll take care of incorporating this point into yo
this is done would be a good idea, but
I don't think we need to say anything in the SGML docs.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
ix the syncscan for everyone else.
I'm inclined to disable use of syncscan.c altogether when the scan is
started backwards. It also seems prudent to suppress ss_report_location
calls when stepping backward in a generally-forwards scan. Thoughts?
regards, tom lane
-
he valid range for parameter
> "autovacuum_vacuum_cost_limit" (-1 .. 1000)
> Note how it still says the range is -1 .. 1000.
Can we redefine things to make zero be the "disabled" value, thus
keeping the range of valid values contiguous?
regards,
arily have PGPROCs.
2. If somebody crashes while holding the lock, the entire system
including the postmaster soon freezes up.
3. Having the postmaster take LWLocks is verboten anyway, mainly because
of problem #2.
regards, tom lane
--
ot as severe as I thought then.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
point, which fixes both my reproducibility concern
and Heikki's original point about being able to re-use cached data.
You'd only get into the irreproducible behavior if the LIMIT was larger
than the amount of data scanned between hint updates.
regards, tom lane
---
st blocks
starting here", not "I have scanned blocks ending here",
which seems like the interpretation that's being used at the moment.
What that would mean is that successive "LIMIT 1000" calls would in fact
all start at the same place, barring int
o "SELECT * ... LIMIT 1"
just to remind themselves of column names or whatever. Do we really
want the thing to be so nannyish? I was envisioning simply a stronger
warning in the SELECT reference page ...
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ngs than we have now
about using LIMIT without ORDER BY.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining colum
f the
moon? I've got a serious problem with that. You might look back to
1997 when GEQO very nearly got tossed out entirely because it destroyed
reproducibility of query results.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
resql.org/pgsql-hackers/2007-02/msg01729.php
We had pretty much agreed that we could handle that by restricting the
conditions under which we'd consider coercing an UNKNOWN literal to
ANYARRAY, but it wasn't quite clear *what* restriction to use.
Comments?
regards, tom
NikhilS <[EMAIL PROTECTED]> writes:
> On 6/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> This still seems to fundamentally misunderstand the difference between
>> an index and a constraint. IMHO it should not be examining pg_index
>> (or specifically, the index Re
e last crash-restart, but that
time is not tracked anywhere AFAIR. I didn't see enough value in the
hint to worry about fixing it; I just took it out.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
s) at all.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
don't remember that.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
ore 8.3 is out (in favor of a generic text cast capability), but we
need a back-patchable fix for the released branches. So the "minimal"
patch looks the best to me --- least risk of patch trouble.
regards, tom lane
---(end of broadca
propriate mblen
or other encoding-dependent function, and then call directly to the
right place in the inner loops instead of having to go through the
intermediate vectoring function every time.
regards, tom lane
---(end of broadcast)-
nc
on character boundaries. And we know that no backend-legal encoding
allows ASCII characters such as '%' to appear as non-first bytes of
characters, so we won't mistakenly detect a new wildcard."
regards, tom lane
--
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think it should be dropped entirely. The argument against was that
>> it complicated the code in a non-performance-critical path, and that
>> argument isn't going to be different next time.
> I
rent next time.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Wed, 2007-05-30 at 15:56 -0400, Tom Lane wrote:
>> In the sync-scan case the idea seems pretty bogus anyway, because the
>> actual working set will be N backends' rings not just one.
> I don't follow. Ideally, in the s
ng set will be N backends' rings not just one.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One other question: I see the patch sets the threshold for switching
>> from normal to ring-buffer heapscans at table size = NBuffers. Why
>> so high? I'd have expected maybe at most NBuffers/4
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The COPY IN part of the patch is not there, pending resolution of
>> whether we think it adds enough value to be worth uglifying
>> heap_insert's API for.
> I ran a series of tests, and it l
jections I'll adjust the patch to include the clock-sweep change.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Joachim Wieland attempted to post this patch, but it appears to be gone.
I trust the applied version will contain neither Windows newlines nor
non-English comments.
regards, tom lane
-
n of the patch that moves
usage_count incrementing to PinBuffer instead of UnpinBuffer. It does
seem a good bit cleaner.
regards, tom lane
binalDuLkt1Ft.bin
Description: buffer-ring-3.patch.gz
---(end of broadcast)-
ons about whether
to bump the access count or not. But at the moment it doesn't seem that
we really need any such info; AFAICS all the callers of PinBuffer know
what they want to happen.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
. Also, I tentatively reduced the threshold
at which heapscans switch to ring mode to NBuffers/16; that probably
needs more thought. Lastly, I haven't done anything about making
non-btree indexes honor the access strategy during VACUUM scans.
regards, tom lane
bi
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2007-28-05 at 15:05 -0400, Tom Lane wrote:
>> Hmmm ... if you check the cvs history for those tests you might find
>> some evidence.
> "Modify regression tests to allow GEQ optimizer (order results).",
>
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2007-28-05 at 15:38 -0400, Tom Lane wrote:
>> More generally, I'm really hoping to get rid of bespoke text<->whatever
>> cast functions in favor of using datatypes' I/O functions.
> I don't object, but
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, so the patch is ready to be applied?
Neil's still reviewing it, last I heard.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our
ed if the clock sweep doesn't touch the usage_count of a
pinned buffer. Which in fact it may not do already --- didn't look.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
igh? I'd have expected maybe at most NBuffers/4 or NBuffers/10.
If you don't want a seqscan blowing out your buffer cache, you surely
don't want it blowing out 90% of the cache either.
regards, tom lane
---(end of broadcast)---
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A point I have not figured out how to deal with is that in the patch as
>> given, UnpinBuffer needs to know the strategy; and getting it that info
>> would make the changes far more invasive. But the
thout
causing problems.
Also, invoking btrim() seems an exceedingly expensive way of ignoring a
bit of whitespace. I suppose inefficiency in a seldom-used cast
function does not matter, but please don't do it that way in boolin.
regards, tom lane
--
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2007-28-05 at 10:50 -0400, Tom Lane wrote:
>> I'd argue that it's an oversight. I don't have a problem with adding up
>> the values of units that really translate to the same thing (eg,
>> '1 we
quired. What I'm tempted to do is remove the special case there and
adjust buffer acquisition instead (maybe make it decrement the
usage_count when re-using a buffer from the ring).
Comments? I'm still playing with the ideas at this point...
regards, tom lane
nt? I suspect that to make it work unsurprisingly, we'd
need to allocate a distinct tmask bit to each logically distinct unit.
(Maybe shortage of tmask bits is why the code is like it is?)
regards, tom lane
---(end of broadcast)
an as preferred if
you EXPLAIN the query after the regression tests complete, right?
Could you step through cost_seqscan and see how it's arriving at such
a high value?
regards, tom lane
---(end of broadcast)---
TIP 7: Y
gree
with yours) for the indexscans. Stranger and stranger.
Would you try inserting a "vacuum verbose pg_constraint" into the test
as well? Maybe that will tell something relevant.
regards, tom lane
---(end of broadcast)--
#x27;t you intending to review these in parallel
because of the possible interactions? Do you think this should be
applied now, or does it need to wait to see what happens with Jeff's
patch?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ng to get it into 8.3 as a contrib module, I recommend
pursuing it as a pgfoundry project, so as to decouple its release
schedule from the backend's.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
did that come from? There's only one row in pg_constraint in standard
template0 --- could he be working with a custom system that has many
more?
regards, tom lane
---(end of broadcast)---
TIP 7: You can
the regression database after a completed regression run, so
it's possible that it's a bit different state from what's seen at the
instant the cluster test was running, but it sure looks like the
"expected" results are what you get from a seqscan. Would you force a
s
he locale
used by the install case?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
y that's happening rather than just throwing an
ORDER BY at it. Considering the number of buildfarm machines that
aren't showing any such problem, there must be something odd about
yours. What's the platform? What plan is being chosen for that SELECT?
reg
t checks to see if 2-column indexes would be more helpful if the column
order were switched. It's incomplete because I didn't do anything about
printing out a nice explanation of what the hypothetical index is.
Comments, objections?
regards, tom lane
regression=
wouldn't be any performance
penalty for switching to SYSV semas. Seems like there is. Comments?
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
c
) and
PQisBusy() on each connection. See
http://www.postgresql.org/docs/8.2/static/libpq-async.html
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
h
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If there's more needed here, let's see an official API change,
>> not a hack.
> Well, I guess the obvious API would be something like:
> PGAsyncStatusType PQasyncStatus(const PGc
ursed mysql more than
once for doing the equivalent. Also, if psql needs more than is
currently exported as official API, why wouldn't other programs need it
too? If there's more needed here, let's see an official API change,
not a hack.
regards, tom lane
;-).
But yes, bogus comments are worth the trouble to fix now.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
it's hardly
fair to hold LIKE INCLUDING INDEXES to a higher standard.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your join
f the system it didn't need to touch. The original suggestion was to
actively refactor existing code, which might or might not have been
worthwhile. But this isn't an appropriate substitute --- it's just
making the API uglier for no particular benefit.
x27;s cheaper to just do that. When and if we have callers with
different usage patterns, we can measure whether it's worth trying to
avoid the memmove(). I'm dubious that it will be a win even then,
since the only way to have a lot of stuff to move is if you don't
trim very often.
anch patches added a dependency on
DTK_ISODOW in the first place. That looks more like a copy&paste
error than something intentional. Michael?
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archiv
before
entering the recursion.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message ca
> for their statment; putting an index on the timestamp+statement seems
> impractical.
Essentially the above is arguing that you want a unique index but you
can't be bothered to invent an actually-unique key. This doesn't seem
a sound argument to me. If we need a unique key, let&#
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> On the strength of this analysis, shouldn't we drop the separate
>> UTF8 match function and just use SB_MatchText for UTF8?
> We still call NextChar() after "_", and I think we probably need to,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> Yeah, quite possibly. I'm also wondering if we are wasting effort
>>> downcasing what will in most cases be the same pattern over and over
&
uld open opportunities for making use of an index on lower(x).
I recall thinking at the time that there were some potential downsides,
but right at the moment I'm darned if I can see any --- especially
if we're going to make ILIKE do this uniformly at runtime anyway.
epending on
whether you want it to be valid for the short-format record in the
compressed file). There will also be some games to be played for
WAL page boundaries, but you had to do that anyway.
regards, tom lane
---(end of broadcast)-
his would leave us with
just two match functions and allow considerable unification of the setup
logic.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
901 - 1000 of 4175 matches
Mail list logo
