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
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
bloats
On 1/23/07, Martijn van Oosterhout kleptog@svana.org 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
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 tuple can
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
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
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 consumed
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
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.
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. A
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 line
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
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); or,
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 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 on the
On Wed, 2007-01-24 at 02:42 +1100, FAST PostgreSQL wrote:
In the UPDATE or DELETE statements the ‘WHERE CURRENT OF cursor_name’
clause results in the cursor name being placed in the UpdateStmt or
DeleteStmt structure. During the processing of the functions -
transformDeleteStmt() and
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
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
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.
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 ..
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.
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 than
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
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,
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
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
---
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
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
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
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 deeper?
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 cursor_nameâ
clause results in the cursor name being placed in the UpdateStmt or
DeleteStmt structure. During the processing of the
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
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 write the
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
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)
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
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 possible
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 cursor_name’
clause results in the cursor name being placed in the UpdateStmt or
[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...
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 misread my
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 Optimizations (HOT)
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 about
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 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 at
execution
* 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:
{ GRANT { {
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
Hi Arul,
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
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 with the
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:
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
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:
* 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, for very
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 fairly new.
Any
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
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 was
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 not
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 line 4 at block
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 for the
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;
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 about the
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
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 CE
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
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
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
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 choice
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
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 go to
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 the fix
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 me,
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 -
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 upskilling
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
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
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 willingness on the
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
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 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
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
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 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 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
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
configuration
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 to
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 possibly
85 matches
Mail list logo
