On 1/24/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On a typical desktop class 2 CPU Dell machine, we have seen pgbench
> clocking more than 1500 tps.
Only if you had fsync off, or equivalently a disk drive that lies about
write-complete. You could po
On 1/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I know it might break the ctid chain, but does that really matter ?
Yes. You can't just decide that the tuple isn't needed anymore.
As per other followup, you could possibly shrink a known-dead tuple
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On a typical desktop class 2 CPU Dell machine, we have seen pgbench
> clocking more than 1500 tps.
Only if you had fsync off, or equivalently a disk drive that lies about
write-complete. You could possibly achieve such rates in a non-broken
configura
On Jan 23, 2007, at 5:50 PM, Joshua D. Drake wrote:
To cure the shortage of experienced Postgres folks there is only one
solution - err, more experience! So the need is for good training
courses (not necessarily certification and all the IMHO nonsense that
comes with that), and a willingness on t
On Jan 23, 2007, at 12:07 PM, Stephen Frost wrote:
Whoa. You are going to allow people to create objects owned by
someone
else? I don't think so ... most Unix systems have forbidden object
give-away for years, for very good reasons.
Hmm. While I agree with the sentiment, Unix does provide
On Jan 22, 2007, at 6:53 PM, Kenneth Marshall wrote:
The default should
be approximately the OS standard read-ahead amount.
Is there anything resembling a standard across the OSes we support?
Better yet, is there a standard call that allows you to find out what
the read-ahead setting is?
-
On 1/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> Another source of I/O is perhaps the CLOG read/writes for checking
> transaction status. If we are talking about large tables like accounts
in
> pgbench or customer/stock in DBT2, the tables are vacuumed much later
Hi Simon,
Thanks for your comments.
The reason for those 5 options is to consider different means to cover the
Prepared Stmt requirement where the different stages of processing are
actually in different transactions.
Regards,
John Bartlett
Software Development Engineer
Fujitsu Australia Softwa
I wrote:
> After further thought I've developed a modified version of Brian's case
> that crashes 8.2 and HEAD but not 8.1 --- it turns the situation around
> by having the view fall back to typmod -1. So what I'm now thinking
> is that the real problem is that an Append path generates its Vars by
Hi Richard,
Thanks for your comments.
I can see where you are coming from but I am not sure if a new log entry
would be such a good idea. The result of creating such a low level log could
be to increase the amount of logging by a rather large amount.
However, the system catalogue will contain a
Mark Kirkwood wrote:
> Joshua D. Drake wrote:
>>> To cure the shortage of experienced Postgres folks there is only one
>>> solution - err, more experience! So the need is for good training
>>> courses (not necessarily certification and all the IMHO nonsense that
>>> comes with that), and a willingn
Joshua D. Drake wrote:
To cure the shortage of experienced Postgres folks there is only one
solution - err, more experience! So the need is for good training
courses (not necessarily certification and all the IMHO nonsense that
comes with that), and a willingness on the part of employers to inves
I wrote:
> I'm tempted to suggest that we just remove the Assert on vartypmod in
> the 8.1 branch. The Assert on vartype is doing as much as is really
> important to check, and I don't want to disable the trivial_subqueryscan
> optimization, which seems the only other low-risk fix.
After further
> To cure the shortage of experienced Postgres folks there is only one
> solution - err, more experience! So the need is for good training
> courses (not necessarily certification and all the IMHO nonsense that
> comes with that), and a willingness on the part of employers to invest
> in upskillin
Theo Schlossnagle wrote:
Get a CCIE and tell me that again :-) When you are handed a complicated
network of routers and switches running all sorts of version of IOS and
CatOS and you go to lunch, they break it and you have a certain time
allotment to fix it all.
I know all about CCIE - o
> Oracle's certification programs have helped Oracle
> considerably in gaining the number of Oracle professionals in the job
> market. PostgreSQL certification has the opportunity to do the same and
> in doing so increase overall PostgreSQL adoption. That's a good thing.
Well maybe it is just m
Brian Hurt <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm, I thought that stack trace looked a bit familiar --- we seem to
>> have fixed the problem as of 8.2. Unfortunately I can't recall what
>> the relevant change was exactly; time for some digging in the CVS logs.
> Any hope of getting
On Tue, Jan 23, 2007 at 05:19:45PM -0500, Theo Schlossnagle wrote:
>
> On Jan 23, 2007, at 5:14 PM, Joshua D. Drake wrote:
>
> >>Get a CCIE and tell me that again :-) When you are handed a
> >>complicated network of routers and switches running all sorts of
> >>version of IOS and CatOS and you
On Jan 23, 2007, at 5:14 PM, Joshua D. Drake wrote:
Get a CCIE and tell me that again :-) When you are handed a
complicated
network of routers and switches running all sorts of version of
IOS and
CatOS and you go to lunch, they break it and you have a certain time
allotment to fix it all
> Get a CCIE and tell me that again :-) When you are handed a complicated
> network of routers and switches running all sorts of version of IOS and
> CatOS and you go to lunch, they break it and you have a certain time
> allotment to fix it all.
>
> Most certifications are not simple multiple ch
On Jan 23, 2007, at 5:04 PM, Mark Kirkwood wrote:
Theo Schlossnagle wrote:
On Jan 23, 2007, at 4:33 PM, David Fetter wrote:
On Tue, Jan 23, 2007 at 11:52:08AM -0200, Iannsp wrote:
Hello,
I did like to know what you think about the postgresql
certifications provided for
PostgreSQL CE http://
Theo Schlossnagle wrote:
>
> On Jan 23, 2007, at 4:33 PM, David Fetter wrote:
>
>> On Tue, Jan 23, 2007 at 11:52:08AM -0200, Iannsp wrote:
>>> Hello,
>>> I did like to know what you think about the postgresql
>>> certifications provided for
>>>
>>> PostgreSQL CE http://www.sraoss.co.jp/postgresql
Theo Schlossnagle wrote:
On Jan 23, 2007, at 4:33 PM, David Fetter wrote:
On Tue, Jan 23, 2007 at 11:52:08AM -0200, Iannsp wrote:
Hello,
I did like to know what you think about the postgresql
certifications provided for
PostgreSQL CE http://www.sraoss.co.jp/postgresql-ce/news_en.html
CertFi
On Tue, Jan 23, 2007 at 04:41:03PM -0500, Theo Schlossnagle wrote:
> On Jan 23, 2007, at 4:33 PM, David Fetter wrote:
> >On Tue, Jan 23, 2007 at 11:52:08AM -0200, Iannsp wrote:
> >>Hello,
> >>I did like to know what you think about the postgresql
> >>certifications provided for
> >>
> >>PostgreSQL
On Jan 23, 2007, at 4:33 PM, David Fetter wrote:
On Tue, Jan 23, 2007 at 11:52:08AM -0200, Iannsp wrote:
Hello,
I did like to know what you think about the postgresql
certifications provided for
PostgreSQL CE http://www.sraoss.co.jp/postgresql-ce/news_en.html
CertFirst http://www.certfirst.c
On Tue, Jan 23, 2007 at 11:52:08AM -0200, Iannsp wrote:
> Hello,
> I did like to know what you think about the postgresql
> certifications provided for
>
> PostgreSQL CE http://www.sraoss.co.jp/postgresql-ce/news_en.html
>
> CertFirst http://www.certfirst.com/postgreSql.htm
>
> My question is ab
I'm working again on the patch for making guc variables fall back to their
default value if they get removed (or commented) in the configuration file.
There is still an issue with custom variables that needs discussion.
Remember that for regular variables we have the following semantics:
BEGIN;
Iannsp wrote:
> Hello,
> I did like to know what you think about the postgresql certifications
> provided for
>
> PostgreSQL CE
> http://www.sraoss.co.jp/postgresql-ce/news_en.html
>
> CertFirst
> http://www.certfirst.com/postgreSql.htm
>
> My question is about the validate of this certification
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> The following testcase(extracted from a much much larger production code
>> sample) results in
>
>> WARNING: TupleDesc reference leak: TupleDesc 0xb3573b88 (2249,1) still
>> referenced
>> CONTEXT: PL/pgSQL function "foo" lin
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> Before discussing "limitations" you should first justify why we need any
>> such concept at all. It was no part of the original TODO item and I
>> cannot see any good use for it.
> There are permissions which are
Tom Lane wrote:
Brian Hurt <[EMAIL PROTECTED]> writes:
Execute, on a fresh database, the following sql, to recreate the bug:
Hmm, I thought that stack trace looked a bit familiar --- we seem to
have fixed the problem as of 8.2. Unfortunately I can't recall what
the relevant change wa
Brian Hurt <[EMAIL PROTECTED]> writes:
> Execute, on a fresh database, the following sql, to recreate the bug:
Hmm, I thought that stack trace looked a bit familiar --- we seem to
have fixed the problem as of 8.2. Unfortunately I can't recall what
the relevant change was exactly; time for some di
On Tue, 23 Jan 2007, Magnus Hagander wrote:
> On Tue, Jan 23, 2007 at 09:31:40AM -0500, Andrew Dunstan wrote:
> > Magnus Hagander wrote:
> > >Hi!
> > >
> > >I get failures for the largeobject regression tests on my vc++ build. I
> > >don't think this has ever worked, given that those tests are fai
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * Tom Lane ([EMAIL PROTECTED]) wrote:
> >> Whoa. You are going to allow people to create objects owned by someone
> >> else? I don't think so ... most Unix systems have forbidden object
> >> give-away for years,
On 1/22/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
Or so... :)
Thought I would do a poll of what is happening in the world for 8.3. I have:
Alvaro Herrera: Autovacuum improvements (maintenance window etc..)
Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions
Jonah Harris
I forgot to mention: core dumps available upon request (obviously I
don't want to post them to the list).
Brian
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
More info on that assert I've hit.
Compile 8.1.6 with configuration options:
./configure --with-perl --enable-debug --enable-cassert
(not sure if --perl is relevent or not, I think not).
This is on Fedora Core 5 on x86-32.
Execute, on a fresh database, the following sql, to recreate the bug:
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> Whoa. You are going to allow people to create objects owned by someone
>> else? I don't think so ... most Unix systems have forbidden object
>> give-away for years, for very good reasons.
> Hmm. While I agree w
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> The following testcase(extracted from a much much larger production code
> sample) results in
> WARNING: TupleDesc reference leak: TupleDesc 0xb3573b88 (2249,1) still
> referenced
> CONTEXT: PL/pgSQL function "foo" line 4 at block variables in
On Wed, 24 Jan 2007, FAST PostgreSQL wrote:
>
> We are trying to develop the updateable cursors functionality into
> Postgresql. I have given below details of the design and also issues we are
> facing. Looking forward to the advice on how to proceed with these issues.
>
> Rgds,
> Arul Shaji
>
H
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Following up on my reply to Joshua, what I'd like to propose is, for
> > comments and suggestions:
>
> > ALTER SCHEMA name [ [ WITH ] [ DEFAULT ] option [ ... ] ]
>
> > where option can be:
>
> > {
On Tue, 2007-01-23 at 10:39 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
> >> This really isn't gonna work, because it assumes that the tuple that is
> >> "current" at the instant of parsing is still going to be "current"
The following testcase(extracted from a much much larger production code
sample) results in
WARNING: TupleDesc reference leak: TupleDesc 0xb3573b88 (2249,1) still
referenced
CONTEXT: PL/pgSQL function "foo" line 4 at block variables initialization
ERROR: tupdesc reference 0xb3573b88 is not
On 1/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Would it help to set the status of the XMIN/XMAX of tuples early enough
such
> that the heap page is still in the buffer cache, but late enough such
that
> the XMIN/XMAX transactions are finished ? How
Pavan Deolasee wrote:
> On 1/23/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>>
>> Or so... :)
>>
>> I am sure there are more, the ones with question marks are unknowns but
>> heard of in the ether somewhere. Any additions or confirmations?
>>
>>
> I have the first phase of Frequent Update Optimi
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
>> This really isn't gonna work, because it assumes that the tuple that is
>> "current" at the instant of parsing is still going to be "current" at
>> execution time.
> Of course thats true, but you've m
[EMAIL PROTECTED] schrieb:
Thx Russel,
I want to control it from software, changing network access via pg_hba
with software doesnt feel right.
possible case
Say I have a Group called Normal_Rights and one called Zero_Rights.
So dB runs as... Normal_Rights(User
On Tue, 2007-01-23 at 09:55 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
> >> In the UPDATE or DELETE statements the ‘WHERE CURRENT OF ’
> >> clause results in the cursor name being placed in the UpdateStmt or
> >
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> The regex code is working with pg_wchar strings, which aren't
>> necessarily the same representation that the OS' wide-char functions
>> expect. If we could guarantee compatibility then the above plan
>> would make sense ...
> it seems to me, that is p
The regex code is working with pg_wchar strings, which aren't
necessarily the same representation that the OS' wide-char functions
expect. If we could guarantee compatibility then the above plan
would make sense ...
it seems to me, that is possible for UTF8 encoding. So isalpha() function may b
Thx Russel,
I want to control it from software, changing network access via pg_hba with
software doesnt feel right.
possible case
Say I have a Group called Normal_Rights and one called Zero_Rights.
So dB runs as... Normal_Rights(User A, User B, User C, User D)
Hello all. It seems I'm tripping an assert in 8.1.6- the assert on line
219 of src/backend/executor/execScan.c (found by running gdb on a core
dump). This is on x86 and Redhat Linux (forget which version). Note
that if I recompile 8.1.6 with asserts turned off the query completes
just fine.
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Would it help to set the status of the XMIN/XMAX of tuples early enough such
> that the heap page is still in the buffer cache, but late enough such that
> the XMIN/XMAX transactions are finished ? How about doing it when the
> bgwriter is about to wri
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> As I can see, that is because of using isalpha (and other is*), tolower &
> toupper instead of isw* and tow* functions. Is any reason to use them? If
> not, I
> can modify regc_locale.c similarly to tsearch2 locale part.
The regex code is working with
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
>> In the UPDATE or DELETE statements the âWHERE CURRENT OF â
>> clause results in the cursor name being placed in the UpdateStmt or
>> DeleteStmt structure. During the processing of the func
On Tue, Jan 23, 2007 at 09:31:40AM -0500, Andrew Dunstan wrote:
> Magnus Hagander wrote:
> >Hi!
> >
> >I get failures for the largeobject regression tests on my vc++ build. I
> >don't think this has ever worked, given that those tests are fairly new.
> >Any quick ideas on what's wrong before I dig
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I know it might break the ctid chain, but does that really matter ?
Yes. You can't just decide that the tuple isn't needed anymore.
As per other followup, you could possibly shrink a known-dead tuple to
just the header.
The notion of keeping linked
Magnus Hagander wrote:
Hi!
I get failures for the largeobject regression tests on my vc++ build. I
don't think this has ever worked, given that those tests are fairly new.
Any quick ideas on what's wrong before I dig deeper?
[snip]
I wonder if this is a line-end issue? Assuming you are wor
Magnus Hagander wrote:
Hi!
I get failures for the largeobject regression tests on my vc++ build. I
don't think this has ever worked, given that those tests are fairly new.
Any quick ideas on what's wrong before I dig deeper?
FWIW: emu managed to trigger a largeobject related failure too (thoug
Hi!
I get failures for the largeobject regression tests on my vc++ build. I
don't think this has ever worked, given that those tests are fairly new.
Any quick ideas on what's wrong before I dig deeper?
//Magnus
*** ./expected/largeobject.out Tue Jan 23 14:55:25 2007
--- ./results/largeobject.ou
I would like to suggest patches for OR-clause optimization and using index for
searching NULLs.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
---(end of broadcas
Pavan Deolasee wrote:
Another source of I/O is perhaps the CLOG read/writes for checking
transaction status. If we are talking about large tables like accounts in
pgbench or customer/stock in DBT2, the tables are vacuumed much later than
the actual UPDATEs. I don't have any numbers to prove yet,
Hello,
I did like to know what you think about the postgresql certifications
provided for
PostgreSQL CE
http://www.sraoss.co.jp/postgresql-ce/news_en.html
CertFirst
http://www.certfirst.com/postgreSql.htm
My question is about the validate of this certification for the clients.
Make difference
On 1/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
ITAGAKI Takahiro wrote:
> BLCKSZ is typically 8192 bytes and sizeof(ItemPointerData) is 4 bytes.
> 1/4 comes from 8192 / 4 = 2048. If we allow zero-size tuples, the line
> pointers area can bloat up to the ratio. We have tuples no less th
On 1/22/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
I've been looking at the way we do vacuums.
The fundamental performance issue is that a vacuum generates
nheapblocks+nindexblocks+ndirtyblocks I/Os. Vacuum cost delay helps to
spread the cost like part payment, but the total is the same.
Joshua D. Drake wrote:
Lukas Kahwe Smith wrote:
Joshua D. Drake wrote:
Great! I will put it on my, "Remember to bug Arul" list :)
Hey Joshua,
could you put this stuff here:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
Sure if you bother to unlock the page for me ;)
hmm ..
ITAGAKI Takahiro wrote:
BLCKSZ is typically 8192 bytes and sizeof(ItemPointerData) is 4 bytes.
1/4 comes from 8192 / 4 = 2048. If we allow zero-size tuples, the line
pointers area can bloat up to the ratio. We have tuples no less than
32 bytes-size, so the area is restricted 256 bytes now.
size
Regexp works differently with no-ascii characters depending on server encoding
(bug.sql contains non-ascii char):
% initdb -E KOI8-R --locale ru_RU.KOI8-R
% psql postgres < bug.sql
true
--
t
(1 row)
true | true
--+--
t| t
(1 row)
% initdb -E UTF8 --locale ru_RU.UTF-8
% psql
Hello
Pavel Stehule: PLpsm
I expect so plpgpsm will be some time (+/- one year) external project. For
8.3 I would to put 2 patches: scrollable cursors and trappable warnings
(maybe not). I have patch for plpgsql for scrollable cursors too. No body
here has experience with SQL/PSM and plpgps
On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
> In the UPDATE or DELETE statements the ‘WHERE CURRENT OF ’
> clause results in the cursor name being placed in the UpdateStmt or
> DeleteStmt structure. During the processing of the functions -
> transformDeleteStmt() and transformUpda
On Mon, Jan 22, 2007 at 09:14:01PM -0500, Stephen Frost wrote:
> * Joshua D. Drake ([EMAIL PROTECTED]) wrote:
> > Thought I would do a poll of what is happening in the world for 8.3. I have:
>
> Another thing which was mentioned previously which I'd really like to
> see happen (and was discussed o
On 1/23/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
Or so... :)
I am sure there are more, the ones with question marks are unknowns but
heard of in the ether somewhere. Any additions or confirmations?
I have the first phase of Frequent Update Optimizations (HOT) patch ready.
But I held it
On Sat, 2007-01-20 at 14:20 +, Simon Riggs wrote:
> On Sat, 2007-01-20 at 23:54 +1100, Gavin Sherry wrote:
> > Windows are slightly more complex though. As you
> > probably know, there are two ways of specifying the window frame: by an
> > absolute number of rows (ROWS N PRECEDING, for example
Pavan Deolasee wrote:
I thought that we can not reclaim the line pointers unless we remove the
corresponding index entries as well. Isn't that the case ? If so, how would
we reclaim the line pointers after the last used one ?
There might be index pointers to dead line pointers in the proposed
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> > * Consider shrinking expired tuples to just their headers.
>
> Yeah, same idea. You suggested in that thread that we should keep the
> headers because of line pointer bloat, but I don't see how that's
> better. You're still going to get some li
On 1/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> So during a sequential or index scan, if a tuple is found to be dead,
the
> corresponding line pointer is marked "unused" and the space is returned
> to a
> free list. This free list is maintained within the page.
On 1/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
ITAGAKI Takahiro wrote:
> Keeping only line pointers itself is not a problem, but it might lead
> bloating of line pointers. If a particular tuple in a page is replaced
> repeatedly, the line pointers area bloats up to 1/4 of the page.
Joshua D. Drake wrote:
Or so... :)
Thought I would do a poll of what is happening in the world for 8.3. I have:
Alvaro Herrera: Autovacuum improvements (maintenance window etc..)
Gavin Sherry: Bitmap Indexes (on disk), possible basic Window functions
Gavin: how's it going with the bitmap inde
ITAGAKI Takahiro wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> wrote:
The overwhelming vast majoirty of tuples are going to be in one or more
indexes. Which means nearly all tuples are going to fall into this
category. So where's the benefit?
The line pointers can not reused, but the space consu
Pavan Deolasee wrote:
I am thinking that maintaining fragmented free space within a heap page
might be a good idea. It would help us to reuse the free space ASAP without
waiting for a vacuum run on the page. This in turn will lead to lesser heap
bloats and also increase the probability of placing
Pavan Deolasee wrote:
One assumption I am making here is that its sufficient to mark the line
pointer
"unused" (reset LP_USED flag) even though there is an index entry pointing
to
the tuple. During index scan, we anyways check for ItemIdIsUsed() before
proceeding further. I know it might break t
"Pavan Deolasee" <[EMAIL PROTECTED]> wrote:
> > The overwhelming vast majoirty of tuples are going to be in one or more
> > indexes. Which means nearly all tuples are going to fall into this
> > category. So where's the benefit?
>
> The line pointers can not reused, but the space consumed by the
On 1/23/07, Martijn van Oosterhout wrote:
On Tue, Jan 23, 2007 at 01:48:08PM +0530, Pavan Deolasee wrote:
> We might not be able to reuse the line pointers because indexes may have
> references to it. All such line pointers will be freed when the page is
> vacuumed during the regular vacuum.
On Tue, Jan 23, 2007 at 01:48:08PM +0530, Pavan Deolasee wrote:
> I am thinking that maintaining fragmented free space within a heap page
> might be a good idea. It would help us to reuse the free space ASAP without
> waiting for a vacuum run on the page. This in turn will lead to lesser heap
> blo
I am thinking that maintaining fragmented free space within a heap page
might be a good idea. It would help us to reuse the free space ASAP without
waiting for a vacuum run on the page. This in turn will lead to lesser heap
bloats and also increase the probability of placing updated tuple in the
s
85 matches
Mail list logo
