Re: [GENERAL] "could not accept SSPI security context"

2012-01-22 Thread Ahmed Shinwari
Hi, In my email, I mistakenly assumed that the next version would be 2.0.12.0, which was not. My bad. I checked the source and confirmed that the 2.0.11.0 has the bug, and the immediate next version (2.0.11.91) has the fix. You can use the version 2.0.11.92

Re: [GENERAL] Best way to create unique primary keys across schemas?

2012-01-22 Thread Scott Marlowe
On Sun, Jan 22, 2012 at 5:19 PM, panam wrote: > Hi, > > If I'd like to have primary keys generated ("numeric" style, no UUIDs) that > are unique across schemas is the best option to allocate a fixed sequence > range (min,max) to the sequences of all schemas? That's how I do it. If you use a bigs

Re: [GENERAL] PGbouncer for Windows 2008

2012-01-22 Thread John R Pierce
On 01/22/12 4:55 PM, Edison So wrote: I downloaded the 64-bit version and extracted it. Unfortunately. it seems that the pbbouncer.exe file is needed to be rebulit (ie. recompiled) according to the following statements from the README file: those statements you reference may well be from the

Re: [GENERAL] PGbouncer for Windows 2008

2012-01-22 Thread Edison So
Thank you for the reply. I downloaded the 64-bit version and extracted it. Unfortunately. it seems that the pbbouncer.exe file is needed to be rebulit (ie. recompiled) according to the following statements from the README file: - Building for WIN32

Re: [GENERAL] Question about (probably wrong) index scan cost for conditional indexes

2012-01-22 Thread Maxim Boguk
On Mon, Jan 23, 2012 at 11:28 AM, Tom Lane wrote: > Maxim Boguk writes: > > But it seems that index scan cost for very narrow/selective conditional > > indexes is greatly overestimated at least in some cases. > > I realized in connection with > http://archives.postgresql.org/pgsql-general/2012-0

Re: [GENERAL] hash options

2012-01-22 Thread dwnoon
This message has been digitally signed by the sender. Re___GENERAL__hash_options.eml Description: Binary data - Hi-Tech Gears Ltd, Gurgaon, India -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://

Re: [GENERAL] hash options

2012-01-22 Thread David W Noon
On Sun, 22 Jan 2012 09:59:55 -0600, Little, Douglas wrote about [GENERAL] hash options: >I'm working on a data warehouse dimensionalization process where I >need to hash a text string to use as the key. I've implemented with >MD5. It works fine, the problem I have is the size of the md5 (32 >b

Re: [GENERAL] Question about (probably wrong) index scan cost for conditional indexes

2012-01-22 Thread Tom Lane
Maxim Boguk writes: > But it seems that index scan cost for very narrow/selective conditional > indexes is greatly overestimated at least in some cases. I realized in connection with http://archives.postgresql.org/pgsql-general/2012-01/msg00459.php that btcostestimate is not correctly estimating

[GENERAL] Best way to create unique primary keys across schemas?

2012-01-22 Thread panam
Hi, If I'd like to have primary keys generated ("numeric" style, no UUIDs) that are unique across schemas is the best option to allocate a fixed sequence range (min,max) to the sequences of all schemas? Thanks panam -- View this message in context: http://postgresql.1045698.n5.nabble.com/Best-w

[GENERAL] Question about (probably wrong) index scan cost for conditional indexes

2012-01-22 Thread Maxim Boguk
I not sure it is bug or just planner work that way. Postgresql 9.1.2 on Linux. But it seems that index scan cost for very narrow/selective conditional indexes is greatly overestimated at least in some cases. In my case I have an special conditional index like: "news_dtime_in208section_active_key

Re: [GENERAL] indexes no longer used after shutdown during reindexing

2012-01-22 Thread Tomas Vondra
On 20.1.2012 19:47, Matt Dew wrote: > On 01/13/2012 02:49 PM, Tomas Vondra wrote: >> On 13.1.2012 22:20, Tom Lane wrote: >>> Matt Dew writes: An interesting sidenote we realized. the nice system shutdown script /etc/init.d/postgres doesn't actually wait for the db to be down, it ju

Re: [GENERAL] Database takes up MUCH more disk space than it should

2012-01-22 Thread Adrian Klaver
On Sunday, January 22, 2012 12:26:22 am Dan Charrois wrote: > > Thank you Adrian. I think that you seem to have found the trouble. For > most of the TOAST tables I have, oid=relfilenode, but not for that one. I > found the table that has reltoastrelid linking to that huge TOAST table.. > and i

Re: [GENERAL] Database takes up MUCH more disk space than it should

2012-01-22 Thread Tom Lane
Dan Charrois writes: > It's too bad \dt+ doesn't take into account the related TOAST table > too - if it had, I would have expected that much disk space right from > the get-go, and never thought twice about it. FWIW, that's been changed as of 9.1. regards, tom lane --

Re: [GENERAL] hash options

2012-01-22 Thread Chris Angelico
On Mon, Jan 23, 2012 at 2:59 AM, Little, Douglas wrote: > > I’ve implemented with MD5.  It works fine,  the problem I have is the size of > the md5 (32 bytes) is often longer than the original string – thus not > accomplishing what I want – space savings. You can always use a truncated hash - f

[GENERAL] hash options

2012-01-22 Thread Little, Douglas
Hello, I'm working on a data warehouse dimensionalization process where I need to hash a text string to use as the key. I've implemented with MD5. It works fine, the problem I have is the size of the md5 (32 bytes) is often longer than the original string - thus not accomplishing what I wan

Re: [GENERAL] Database takes up MUCH more disk space than it should

2012-01-22 Thread John R Pierce
On 01/22/12 12:32 AM, Dan Charrois wrote: It looks like a large TOAST table, not reported by \dt+ was the biggest culprit, but I thought it was orphaned. Due to some help by Adrian Klaver, it looks like I was mistaken - it was in fact used by one of my tables. So it looks like there wasn't r

Re: [GENERAL] Database takes up MUCH more disk space than it should

2012-01-22 Thread Dan Charrois
On 2012-Jan-21, at 6:39 PM, Scott Marlowe wrote: > On Sat, Jan 21, 2012 at 1:37 AM, Dan Charrois wrote: >> Hi everyone. I'm currently in the situation of administering a rather large >> PostgreSQL database which for some reason seems to be even much larger than >> it should be. >> >> I'm cur

Re: [GENERAL] Database takes up MUCH more disk space than it should

2012-01-22 Thread Dan Charrois
>> >> SELECT relname, pg_size_pretty(relpages::bigint * 8 *1024) AS size, CASE >> WHEN relkind = 't' THEN (SELECT pgd.relname FROM pg_class pgd WHERE >> pgd.relfilenode::text = SUBSTRING(pg.relname FROM 10)) ELSE (SELECT >> pgc.relname FROM pg_class pgc WHERE pg.reltoastrelid = pgc.relfilenode) >>