Re: [HACKERS] *sigh*
How about: Implement a function "estimated_count" that can be used instead of "count". It could use something like the algorithm in src/backend/commands/analyze.c to get a reasonably accurate psuedo count quickly. The advantage of this approach is that "count" still means (exact)count (for your xact snapshot anyway). Then the situation becomes: Want a fast count? - use estimated_count(*) Want an exact count - use count(*) regards Mark Christopher Browne wrote: For a small table, it will be cheaper to walk through and calculate count(*) directly from the tuples themselves. The situation where it may be worthwhile to do this is a table which is rather large (thus count(*) is expensive) where there is some special reason to truly care how many rows there are in the table. For _most_ tables, it seems unlikely that this will be true. For _most_ tables, it is absolutely not worth the cost of tracking the information. ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] *sigh*
Fairly good idea IMHO, especially considering Christopher's point about the unlikeliness of needing an exact count anyway. Regards, Christoph > > How about: > > Implement a function "estimated_count" that can be used instead of > "count". It could use something like the algorithm in > src/backend/commands/analyze.c to get a reasonably accurate psuedo count > quickly. > > The advantage of this approach is that "count" still means (exact)count > (for your xact snapshot anyway). Then the situation becomes: > > Want a fast count? - use estimated_count(*) > Want an exact count - use count(*) > > regards > > Mark > > Christopher Browne wrote: > > >For a small table, it will be cheaper to walk through and calculate > >count(*) directly from the tuples themselves. > > > >The situation where it may be worthwhile to do this is a table which > >is rather large (thus count(*) is expensive) where there is some > >special reason to truly care how many rows there are in the table. > >For _most_ tables, it seems unlikely that this will be true. For > >_most_ tables, it is absolutely not worth the cost of tracking the > >information. > > > > ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Encoding problem with 7.4
On Fri, 28 Nov 2003, Tom Lane wrote: > "E.Rodichev" <[EMAIL PROTECTED]> writes: > > /e:2>createdb test > > > test | er | SQL_ASCII <- Incorrect! > > (3 rows) > > > Let's note than the last line is in fact completely incorrect. > > What's incorrect about it? You didn't ask for any other encoding > than SQL_ASCII. It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII in this example, as I explained in my mail. Best wishes, E.R. > > You can set the default encoding at initdb time, IIRC, but you didn't. > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > _ Evgeny Rodichev Sternberg Astronomical Institute email: [EMAIL PROTECTED] Moscow State University Phone: 007 (095) 939 2383 Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Encoding problem with 7.4
E.Rodichev writes: > It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII > in this example, as I explained in my mail. The encoding is only a declaration of your intentions. What you actually put into the database is your responsibility. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] 7.3.5 bundled ...
On Tue, 2003-12-02 at 23:12, Marc G. Fournier wrote:
>
> Please take a quick peak at it ...
>
> ftp://ftp.postgresql.org/pub/source/v7.3.5
>
>
>
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
>
> ---(end of broadcast)---
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
Built fine on the phppgadmin demo server.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Encoding problem with 7.4
E.Rodichev wrote: On Fri, 28 Nov 2003, Tom Lane wrote: "E.Rodichev" <[EMAIL PROTECTED]> writes: /e:2>createdb test test | er | SQL_ASCII <- Incorrect! (3 rows) Let's note than the last line is in fact completely incorrect. What's incorrect about it? You didn't ask for any other encoding than SQL_ASCII. It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII in this example, as I explained in my mail. Best wishes, E.R. You can set the default encoding at initdb time, IIRC, but you didn't. You can set the default at initdb time, or per database at createdb time, but it has to be done explicitly. You seem to think it should be picked up from the environment, but this isn't so, you must use the -E|--encoding flag on either createdb or initdb, or if creating directly from SQL use the ENCODING option on "create database" to use something other than the default set by initdb. examples: [EMAIL PROTECTED] bin]$ ./initdb /tmp/enctry The files belonging to this database system will be owned by user "andrew". This user must also own the server process. The database cluster will be initialized with locales: COLLATE: ru_RU.KOI8-R CTYPE:ru_RU.KOI8-R MESSAGES: en_US.iso885915 MONETARY: en_US.iso885915 NUMERIC: en_US.iso885915 TIME: en_US.iso885915 creating directory /tmp/enctry... ok creating directory /tmp/enctry/base... ok creating directory /tmp/enctry/global... ok creating directory /tmp/enctry/pg_xlog... ok creating directory /tmp/enctry/pg_clog... ok selecting default max_connections... 100 selecting default shared_buffers... 1000 creating configuration files... ok creating template1 database in /tmp/enctry/base/1... ok initializing pg_shadow... ok enabling unlimited row size for system tables... ok initializing pg_depend... ok creating system views... ok loading pg_description... ok creating conversions... ok setting privileges on built-in objects... ok creating information schema... ok vacuuming database template1... ok copying template1 to template0... ok Success. You can now start the database server using: ./postmaster -D /tmp/enctry or ./pg_ctl -D /tmp/enctry -l logfile start [EMAIL PROTECTED] bin]$ ./pg_ctl -D /tmp/enctry -l /tmp/enclog -o '-p 5433' start postmaster successfully started [EMAIL PROTECTED] bin]$ ./createdb -E KOI8-R -p 5433 testme CREATE DATABASE [EMAIL PROTECTED] bin]$ ./psql -p 5433 -l List of databases Name| Owner | Encoding ---++--- template0 | andrew | SQL_ASCII template1 | andrew | SQL_ASCII testme| andrew | KOI8 (3 rows) [EMAIL PROTECTED] bin]$ ./pg_ctl -D /tmp/enctry -o '-p 5433' stop waiting for postmaster to shut down..done postmaster successfully shut down [EMAIL PROTECTED] bin]$ rm -rf /tmp/enctry [EMAIL PROTECTED] bin]$ ./initdb -E KOI8-R /tmp/enctry The files belonging to this database system will be owned by user "andrew". This user must also own the server process. The database cluster will be initialized with locales: COLLATE: ru_RU.KOI8-R CTYPE:ru_RU.KOI8-R MESSAGES: en_US.iso885915 MONETARY: en_US.iso885915 NUMERIC: en_US.iso885915 TIME: en_US.iso885915 creating directory /tmp/enctry... ok creating directory /tmp/enctry/base... ok creating directory /tmp/enctry/global... ok creating directory /tmp/enctry/pg_xlog... ok creating directory /tmp/enctry/pg_clog... ok selecting default max_connections... 100 selecting default shared_buffers... 1000 creating configuration files... ok creating template1 database in /tmp/enctry/base/1... ok initializing pg_shadow... ok enabling unlimited row size for system tables... ok initializing pg_depend... ok creating system views... ok loading pg_description... ok creating conversions... ok setting privileges on built-in objects... ok creating information schema... ok vacuuming database template1... ok copying template1 to template0... ok Success. You can now start the database server using: ./postmaster -D /tmp/enctry or ./pg_ctl -D /tmp/enctry -l logfile start [EMAIL PROTECTED] bin]$ ./pg_ctl -D /tmp/enctry -l /tmp/enclog -o '-p 5433' start postmaster successfully started [EMAIL PROTECTED] bin]$ ./createdb -p 5433 testme CREATE DATABASE [EMAIL PROTECTED] bin]$ ./psql -p 5433 -l List of databases Name| Owner | Encoding ---++-- template0 | andrew | KOI8 template1 | andrew | KOI8 testme| andrew | KOI8 (3 rows) [EMAIL PROTECTED] bin]$ cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Inside the Regex Engine
Tom Lane wrote: [EMAIL PROTECTED] (David Fetter) writes: While PL/Perl is great, it's not available everywhere, and I'd like to be able to grab atoms from a regex match in, say, a SELECT. Is there some way to get access to them? There's a three-parameter variant of substring() that allows extraction of a portion of a regex match --- unfortunately it uses SQL99's brain-dead notion of regex, which will not satisfy any Perl weenie :-( I think it'd be worth our while to define some comparable functionality that depends only on the POSIX regex engine ... substitute should be relatively straightforward, I guess; split and match maybe less so - what do you return? An array? Or you could require an explicit subscript to get a particular return value as in split_part(), which would be potentially inefficient if you want more than one (although I guess results could be cached). cheers andrew ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] Encoding problem with 7.4
On Wed, 3 Dec 2003, E.Rodichev wrote: > On Fri, 28 Nov 2003, Tom Lane wrote: > > > "E.Rodichev" <[EMAIL PROTECTED]> writes: > > > /e:2>createdb test > > > > > test | er | SQL_ASCII <- Incorrect! > > > (3 rows) > > > > > Let's note than the last line is in fact completely incorrect. > > > > What's incorrect about it? You didn't ask for any other encoding > > than SQL_ASCII. > > It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII > in this example, as I explained in my mail. No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII since you didn't override the default encoding at initdb time or at createdb time. You did choose LC_ values that seem to want KOI8, but locale and encoding are separate, if you want KOI8 encoding, you have to say so. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] BTree index and optimizer
Hello: I am trying to find out, how is the B-tree index implemented for multiple columns? does Postgres, just concatenate the columns --- if this is the case, then how is the search performed? Also, does the optimizer choose the index, only when the constraining is on the leading subset of the index column? Thanks VJ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] postgresql-7.4 make error: tuptoaster.c: In function `toast_delete_datum'
im not sure if this is the correct mailing list, please correct me if it is not. my gcc is version 3.2, configure runs fine i deativated readline-support...but this error occours: gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -D_GNU_SOURCE -c -o tuptoaster.o tuptoaster.c tuptoaster.c: In function `toast_delete_datum': tuptoaster.c:973: `F_OIDEQ' undeclared (first use in this function) any ideas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgresql-7.4 make error: tuptoaster.c: In function `toast_delete_datum'
julius <[EMAIL PROTECTED]> writes: > tuptoaster.c: In function `toast_delete_datum': > tuptoaster.c:973: `F_OIDEQ' undeclared (first use in this function) This suggests that the src/backend/utils/Gen_fmgrtab.sh script did not execute correctly. With no details about your platform, it's hard to say more than that. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Encoding problem with 7.4
On Wed, 3 Dec 2003, Stephan Szabo wrote: > > On Wed, 3 Dec 2003, E.Rodichev wrote: > > > On Fri, 28 Nov 2003, Tom Lane wrote: > > > > > "E.Rodichev" <[EMAIL PROTECTED]> writes: > > > > /e:2>createdb test > > > > > > > test | er | SQL_ASCII <- Incorrect! > > > > (3 rows) > > > > > > > Let's note than the last line is in fact completely incorrect. > > > > > > What's incorrect about it? You didn't ask for any other encoding > > > than SQL_ASCII. > > > > It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII > > in this example, as I explained in my mail. > > No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII > since you didn't override the default encoding at initdb time or at > createdb time. You did choose LC_ values that seem to want KOI8, but > locale and encoding are separate, if you want KOI8 encoding, you have to > say so. Yes, it is! If db "test" is SQL_ASCII, AND all LC_* env are set to "C", the sorting of ASCII characters is, for example, a A b B c C not A B C a b c (the first order is true for ru_RU.KOI8-R, the latter one - for C). To summarize shortly: - initdb _without_ -E flag, but with ru_RU.KOI8-R environment; - createdb with any environment; - psql indicates SQL_ASCII; - sorting and upper/lowercasing are in ru_RU.KOI8-R, even with LC_* environment is set to "C". Where is the logic? Best wishes, E.R. ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] Encoding problem with 7.4
E.Rodichev wrote: On Wed, 3 Dec 2003, Stephan Szabo wrote: On Wed, 3 Dec 2003, E.Rodichev wrote: On Fri, 28 Nov 2003, Tom Lane wrote: "E.Rodichev" <[EMAIL PROTECTED]> writes: /e:2>createdb test test | er | SQL_ASCII <- Incorrect! (3 rows) Let's note than the last line is in fact completely incorrect. What's incorrect about it? You didn't ask for any other encoding than SQL_ASCII. It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII in this example, as I explained in my mail. No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII since you didn't override the default encoding at initdb time or at createdb time. You did choose LC_ values that seem to want KOI8, but locale and encoding are separate, if you want KOI8 encoding, you have to say so. Yes, it is! If db "test" is SQL_ASCII, AND all LC_* env are set to "C", the sorting of ASCII characters is, for example, a A b B c C not A B C a b c (the first order is true for ru_RU.KOI8-R, the latter one - for C). To summarize shortly: - initdb _without_ -E flag, but with ru_RU.KOI8-R environment; - createdb with any environment; - psql indicates SQL_ASCII; - sorting and upper/lowercasing are in ru_RU.KOI8-R, even with LC_* environment is set to "C". Where is the logic? Encoding and collation order are two different things. LC_* settings have no effect on encoding. see http://www.postgresql.org/docs/current/static/charset.html cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Encoding problem with 7.4
On Wed, Dec 03, 2003 at 11:42:34PM +0300, E.Rodichev wrote: > On Wed, 3 Dec 2003, Stephan Szabo wrote: > > > No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII > > since you didn't override the default encoding at initdb time or at > > createdb time. You did choose LC_ values that seem to want KOI8, but > > locale and encoding are separate, if you want KOI8 encoding, you have to > > say so. > > Yes, it is! What apparently you haven't picked up yet is that the _locale_ is a different and unrelated configuration setting from the _encoding_. Sort order is locale related; you already got that one right. Now you need to go after the encoding. -- Alvaro Herrera () "El destino baraja y nosotros jugamos" (A. Schopenhauer) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Encoding problem with 7.4
On Wed, 3 Dec 2003, E.Rodichev wrote: > On Wed, 3 Dec 2003, Stephan Szabo wrote: > > > > > On Wed, 3 Dec 2003, E.Rodichev wrote: > > > > > On Fri, 28 Nov 2003, Tom Lane wrote: > > > > > > > "E.Rodichev" <[EMAIL PROTECTED]> writes: > > > > > /e:2>createdb test > > > > > > > > > test | er | SQL_ASCII <- Incorrect! > > > > > (3 rows) > > > > > > > > > Let's note than the last line is in fact completely incorrect. > > > > > > > > What's incorrect about it? You didn't ask for any other encoding > > > > than SQL_ASCII. > > > > > > It is incorrect, because database "test" is, really, in KOI8, NOT in SQL_ASCII > > > in this example, as I explained in my mail. > > > > No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII > > since you didn't override the default encoding at initdb time or at > > createdb time. You did choose LC_ values that seem to want KOI8, but > > locale and encoding are separate, if you want KOI8 encoding, you have to > > say so. > > Yes, it is! *sigh* > (the first order is true for ru_RU.KOI8-R, the latter one - for C). > > To summarize shortly: > > - initdb _without_ -E flag, but with ru_RU.KOI8-R environment; > - createdb with any environment; > - psql indicates SQL_ASCII; > - sorting and upper/lowercasing are in ru_RU.KOI8-R, even with LC_* > environment is set to "C". Only the locale settings at initdb time matter. Changing the LC_* later is not going to change what the database does. Encoding and locale are separate (but related) and it is your responsibility to make sure the choices are consistent. If you do not specify an encoding, SQL_ASCII is used for the encoding. If the characters happen to line up appropriately for what your ru_RU.KOI8-R locale expects it'll even happen to appear to work for sorting and case changes (and things like isprint). Which part of this are you not understanding? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Encoding problem with 7.4
On Wed, 3 Dec 2003, Alvaro Herrera wrote: > On Wed, Dec 03, 2003 at 11:42:34PM +0300, E.Rodichev wrote: > > On Wed, 3 Dec 2003, Stephan Szabo wrote: > > > > > No, it isn't. As far as PostgreSQL is concerned the database is SQL_ASCII > > > since you didn't override the default encoding at initdb time or at > > > createdb time. You did choose LC_ values that seem to want KOI8, but > > > locale and encoding are separate, if you want KOI8 encoding, you have to > > > say so. > > > > Yes, it is! > > What apparently you haven't picked up yet is that the _locale_ is a > different and unrelated configuration setting from the _encoding_. > Sort order is locale related; you already got that one right. Now you Sorry, I got it WRONG! Sort order for C locale MUST be the abcABC, not aAbBcC. But I got aAbBcC. Best wishes, E.R. > need to go after the encoding. > > -- > Alvaro Herrera () > "El destino baraja y nosotros jugamos" (A. Schopenhauer) > _ Evgeny Rodichev Sternberg Astronomical Institute email: [EMAIL PROTECTED] Moscow State University Phone: 007 (095) 939 2383 Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Encoding problem with 7.4
On Wed, 3 Dec 2003, Andrew Dunstan wrote: > Encoding and collation order are two different things. LC_* settings > have no effect on encoding. > > see http://www.postgresql.org/docs/current/static/charset.html I am trying to point out to reverse dependency: encoding (1) has effect on LC_* settings and (2) the indication of encoding is incorrect. Is it right? Regards, E.R. > > cheers > > andrew > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > _ Evgeny Rodichev Sternberg Astronomical Institute email: [EMAIL PROTECTED] Moscow State University Phone: 007 (095) 939 2383 Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Encoding problem with 7.4
On Wed, 3 Dec 2003, Stephan Szabo wrote: > Only the locale settings at initdb time matter. Changing the LC_* later > is not going to change what the database does. Encoding and locale are > separate (but related) and it is your responsibility to make sure the > choices are consistent. If you do not specify an encoding, SQL_ASCII is > used for the encoding. If the characters happen to line up appropriately > for what your ru_RU.KOI8-R locale expects it'll even happen to appear to > work for sorting and case changes (and things like isprint). Which part of > this are you not understanding? Thank you, it is much more consistent answer. But again, the things are going not exactly the way you wrote. >From your opinion the chain is data -> encoding transform -> locale transform -> output It looks clean and reasonable. Encoding transform may be set during initdb or createdb (is it true?) But when locale transform is defined? In general unix flavor it should depend on LC_* setting (is it true?) As I described in my first posting the situation is different. Namely, locale setting now defines _encoding transform_ (and data representation in storage), but _locale transform_ doesnt depend on LC_*. Best wishes, E.R. _ Evgeny Rodichev Sternberg Astronomical Institute email: [EMAIL PROTECTED] Moscow State University Phone: 007 (095) 939 2383 Fax: 007 (095) 932 8841 http://www.sai.msu.su/~er ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] PostgreSQL 7.3.4 gets killed by SIG_KILL
I have this big table running on an old linux install (kernel 2.2.25). I've COPYed some tcpip logs into a table created as such: create table ipstats (time timestamp, src inet, dst inet, npackets int8, nbytes int8); Big: select count(*) from ipstats; count -- 99173733 When i do two selects some from that table multiple times, the the backend doing the selects is getting killed by signal 9. The select pair look like: select sum(nbytes) from ipstats where dst = '10.10.10.170'; select sum(nbytes) from ipstats where src = '10.10.10.170'; This is what the serverlog says: LOG: server process (pid 20308) was terminated by signal 9 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing shared memory and semaphores FATAL: The database system is starting up LOG: database system was interrupted at 2003-12-03 23:21:49 CET FATAL: The database system is starting up LOG: checkpoint record is at 3/9095BC20 LOG: redo record is at 3/9095BC20; undo record is at 0/0; shutdown TRUE LOG: next transaction id: 8716399; next oid: 141842933 LOG: database system was not properly shut down; automatic recovery in progress LOG: ReadRecord: record with zero length at 3/9095BC60 LOG: redo is not required LOG: database system is ready When i attach a gdb to the process it doesn't help, it exits immediatly anyways. This i believe is because SIG_KILL is "unstoppable"... Any ideas as of what to do? Regards Magnus ---(end of broadcast)--- TIP 3: 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
Re: [HACKERS] Inside the Regex Engine
Andrew Dunstan <[EMAIL PROTECTED]> wrote: > Tom Lane wrote: > >>[EMAIL PROTECTED] (David Fetter) writes: >> >> >>>While PL/Perl is great, it's not available everywhere, and I'd like >>>to be able to grab atoms from a regex match in, say, a SELECT. Is >>>there some way to get access to them? >> >>There's a three-parameter variant of substring() that allows >>extraction of a portion of a regex match --- unfortunately it uses >>SQL99's brain-dead notion of regex, which will not satisfy any Perl >>weenie :-( >> >>I think it'd be worth our while to define some comparable >>functionality that depends only on the POSIX regex engine ... > > substitute should be relatively straightforward, I guess; split and > match maybe less so - what do you return? An array? That would be great. > Or you could require an explicit subscript to get a particular > return value as in split_part(), which would be potentially > inefficient if you want more than one (although I guess results > could be cached). That'd be good, too. Cheers D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 My definition of a free society is a society where it is safe to be unpopular. Adlai Stevenson ---(end of broadcast)--- TIP 3: 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
[HACKERS] relation_byte_size()
Hackers
Here is the definition of relation_byte_size() in optimizer/path/costsize.c:
--
/*
* relation_byte_size
*Estimate the storage space in bytes for a given number of tuples
*of a given width (size in bytes).
*/
static double
relation_byte_size(double tuples, int width)
{
return tuples * (MAXALIGN(width) + MAXALIGN(sizeof(HeapTupleData)));
}
--
Shouldn't this be HeapTupleHeaderData and not HeapTupleData ?
(Of course, from a costing perspective these shouldn't be very different but ...)
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PostgreSQL 7.3.4 gets killed by SIG_KILL
"Magnus Naeslund(t)" <[EMAIL PROTECTED]> writes: > I have this big table running on an old linux install (kernel 2.2.25). > I've COPYed some tcpip logs into a table created as such: Linux is probably killing your process because it (the kernel) is low on memory. Unfortunately, this happens more often with older versions of the kernel. Add more RAM/swap or figure out how to make your query use less memory... -Doug ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Encoding problem with 7.4
On Thu, 4 Dec 2003, E.Rodichev wrote: > On Wed, 3 Dec 2003, Stephan Szabo wrote: > > > Only the locale settings at initdb time matter. Changing the LC_* later > > is not going to change what the database does. Encoding and locale are > > separate (but related) and it is your responsibility to make sure the > > choices are consistent. If you do not specify an encoding, SQL_ASCII is > > used for the encoding. If the characters happen to line up appropriately > > for what your ru_RU.KOI8-R locale expects it'll even happen to appear to > > work for sorting and case changes (and things like isprint). Which part of > > this are you not understanding? > > > Thank you, it is much more consistent answer. But again, the things are > going not exactly the way you wrote. > > >From your opinion the chain is > > data -> encoding transform -> locale transform -> output > > It looks clean and reasonable. > > Encoding transform may be set during initdb or createdb (is it true?) > > But when locale transform is defined? In general unix flavor it should > depend on LC_* setting (is it true?) > > As I described in my first posting the situation is different. Namely, > locale setting now defines _encoding transform_ (and data representation > in storage), but _locale transform_ doesnt depend on LC_*. The locale settings depend on LC_* at initdb time only. When the postmaster starts it sets the locale based on the stored values from initdb, not on the current environment. With an SQL_ASCII database being accessed from a client with client_encoding set to SQL_ASCII (which it should be if you aren't setting it) the byte values of a string are passed along with no conversion for the encoding. This means that from within one environment you should get back what you put in, so it might *look* like it's KOI8-R if that's what you're in, but it's not because someone accessing it from say an ISO8859-1 system may see something different. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL 7.3.4 gets killed by SIG_KILL
Doug McNaught wrote: "Magnus Naeslund(t)" <[EMAIL PROTECTED]> writes: I have this big table running on an old linux install (kernel 2.2.25). I've COPYed some tcpip logs into a table created as such: Linux is probably killing your process because it (the kernel) is low on memory. Unfortunately, this happens more often with older versions of the kernel. Add more RAM/swap or figure out how to make your query use less memory... -Doug Well this just isn't the case. There is no printout in kernel logs/dmesg (as it would be if the kernel killed it in an OOM situation). I have 1 GB of RAM, and 1.5 GB of swap (swap never touched). When running the query i have about 850 MB sitting in kernel cache, the postgres process takes about 40MB of memory, and the ipcs -m command shows that postgresql is taking 41508864 bytes of shared memory. There is no sorting or index lookups going on, the query is simple. I just had an power outage, i'll check if it maybe wised up after reboot or something, but i doubt it. Is it possible to somehow find out what process sent the KILL (or if it's the kernel) ? I find this very weird to say the least... Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
