On Wed, 2007-07-04 at 22:27 +0100, Gregory Stark wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > Catalog bloat is one unwanted effect. Second is different behave of
> > temp tables than other mayor rdbms, and uncomfortable work with temp
> > tables in stored procedures. Third argument fo
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
>> The solution is to fix the bloat, not add a work-around.
>
>> The bloat is a direct consequence of performing DDL in the midst of an OLTP
>> transaction.
>
> Hard
Gregory Stark <[EMAIL PROTECTED]> writes:
>> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
> The solution is to fix the bloat, not add a work-around.
> The bloat is a direct consequence of performing DDL in the midst of an OLTP
> transaction.
Hardly. It's a consequence of our current implementati
Hello,
I'm trying to write a trigger function which uses GRANT ROLE statement.
Scenario is: I have a group role (let's call it A) which has not superuser
privileges and I want to grant A membership to current user after an insert on
a particular table, then revoke it after a delete on it; I writ
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> I'm still struggling to understand why and how bgwriter increases
>>> performance.
>>> Under what circumstances, what workload?
>>>
>>> The only benefit I can
Gregory Stark wrote:
>
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> >> FWIW, I normally go with the 8.2 defaults, though I could see dropping
> >> vacuum_scale_factor down to 0.1 or 0.15. I also think the thresholds
> >> could be decreased further, maybe divide by 10.
> >
> > How about push
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>> FWIW, I normally go with the 8.2 defaults, though I could see dropping
>> vacuum_scale_factor down to 0.1 or 0.15. I also think the thresholds
>> could be decreased further, maybe divide by 10.
>
> How about pushing thresholds all the way down to 0?
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
>> > The use case is any system that uses temp tables in an OLTP setting,
>> > which certainly isn't uncommon. The problem is that today (and as well
>> > with a global temp table that is still writing to th
Gregory Stark <[EMAIL PROTECTED]> writes:
> Let me put it another way, how would I write a test case to cover these lines
> of code and not receive an error from replanning?
"Hard to get to" is not the same as "dead code". An example is that
third-party add-ons might re-use plans that are not com
Pavel Stehule wrote:
> 2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
> > > The use case is any system that uses temp tables in an OLTP setting,
> > > which certainly isn't uncommon. The problem is that today (and as well
> > > with a global temp table that is still writing to the catalogs) is that
>
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Should this case at heaptuple.c:1606 be turned into an elog() now that we
>> have
>> plan cache invalidation?
>
> No, I think it's good as-is. Reading the column as null is the correct
> behavior.
Isn't the c
Gregory Stark <[EMAIL PROTECTED]> writes:
> Should this case at heaptuple.c:1606 be turned into an elog() now that we have
> plan cache invalidation?
No, I think it's good as-is. Reading the column as null is the correct
behavior.
regards, tom lane
--
Gregory Stark <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I'm still struggling to understand why and how bgwriter increases
>> performance.
>> Under what circumstances, what workload?
>>
>> The only benefit I can see is that it moves the write() of a page out o
Currently libpq provides a function to escape byteas to include directly in
the query string. But if you're using PQexecParam you still need to do one
layer of quoting but don't need to double the backslashes which PQescapeBytea
does if you have standard_conforming_strings set off.
Do we want som
On Tuesday 03 July 2007 19:35, Tom Lane wrote:
> It seems like we see a remarkable number of occurrences of $subject.
> For instance, right now we have these members failing on various
> branches:
>
> echidna No space left on device
> asp No space left on device
> herring
Should this case at heaptuple.c:1606 be turned into an elog() now that we have
plan cache invalidation? If it "can't" happen then it's probably better that
we find out if it does happen rather than silently run the old plan and return
nulls.
/*
* If the attribute's column has bee
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Greg Smith wrote:
> > Here are some more recent papers that also give good insight into research
> > in
> > this area:
> > http://www.cs.usask.ca/~wew036/comprehensive.pdf
> > http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-05-3
Hello.
I think it could be a nice idea to put descriptions from
http://www.postgresql.org/docs/8.2/static/catalogs.html
into system catalogs itself. I.e., make a bunch of
COMMENT ON COLUMN pg_class.relname
IS 'Name of the table, index, view, etc.';
...
COMMENT ON COLUMN pg_class.relkind
I
Martijn van Oosterhout wrote:
On Wed, Jul 04, 2007 at 11:09:19AM +0100, Heikki Linnakangas wrote:
The only benefit I can see is that it moves the write() of a page out of
the critical path. But as long as the OS cache can absorb the write, it
should be very cheap compared to doing real I/O. App
On Wed, Jul 04, 2007 at 11:09:19AM +0100, Heikki Linnakangas wrote:
> The only benefit I can see is that it moves the write() of a page out of
> the critical path. But as long as the OS cache can absorb the write, it
> should be very cheap compared to doing real I/O. Apparently the workload
> th
Greg Smith wrote:
Here are some more recent papers that also give good insight into
research in this area:
http://www.cs.usask.ca/~wew036/comprehensive.pdf
http://www.cse.ohio-state.edu/hpcs/WWW/HTML/publications/papers/TR-05-3.pdf
Nice papers.
What I'd like to see is a paper on precleaning
Martijn van Oosterhout wrote:
On Tue, Jul 03, 2007 at 09:51:59PM -0400, Tom Lane wrote:
Out-of-line datums aren't the only issue, either: consider inline
compressed datums. A data representation change, even one that is known
not to increase the ordinary uncompressed size of the datum, could
ea
On Tue, Jul 03, 2007 at 09:51:59PM -0400, Tom Lane wrote:
> Out-of-line datums aren't the only issue, either: consider inline
> compressed datums. A data representation change, even one that is known
> not to increase the ordinary uncompressed size of the datum, could
> easily render it slightly l
Tom Lane wrote:
I do not expect that old code will work with new index structure. I want
to keep both implementation and old index will be processed by old code
and new one will be processed by new implementation. Each will have
different OID and pg_class.relam will point to correct implemen
2007/7/4, Bruce Momjian <[EMAIL PROTECTED]>:
> The use case is any system that uses temp tables in an OLTP setting,
> which certainly isn't uncommon. The problem is that today (and as well
> with a global temp table that is still writing to the catalogs) is that
> every OLTP operation that create
25 matches
Mail list logo
