Thread: Top five challenges
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Josh Berkus said in another thread: > Back in 2007, at Sun I hired an industry analyst to do research give me > a list of the 5 biggest items inhibiting PostgreSQL community growth and > large enterprise adoption. The lack of "all-in-one packages" was item > #3. The fact that EnterpriseDB eliminated that item has expanded our > community and user base to many people who never tried PostgreSQL before. So refresh us again what the top five were? - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201102252310 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk1ofVAACgkQvJuQZxSWSsjuWwCeIiBRjuQR6VxDOIwMO7fNkNe5 QRYAnR+tJ1MN7fQ1s/NYauE5jE5DlzO7 =Gw8V -----END PGP SIGNATURE-----
On Fri, Feb 25, 2011 at 11:11 PM, Greg Sabino Mullane <greg@turnstep.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > Josh Berkus said in another thread: > >> Back in 2007, at Sun I hired an industry analyst to do research give me >> a list of the 5 biggest items inhibiting PostgreSQL community growth and >> large enterprise adoption. The lack of "all-in-one packages" was item >> #3. The fact that EnterpriseDB eliminated that item has expanded our >> community and user base to many people who never tried PostgreSQL before. > > So refresh us again what the top five were? > > - -- good post Greg. I meant to ask the same earlier in the day. Give it up Josh. :-) -- Mike Ellsworth
On 2/25/11 8:11 PM, Greg Sabino Mullane wrote:
>
> Josh Berkus said in another thread:
>
>> Back in 2007, at Sun I hired an industry analyst to do research give me
>> a list of the 5 biggest items inhibiting PostgreSQL community growth and
>> large enterprise adoption. The lack of "all-in-one packages" was item
>> #3. The fact that EnterpriseDB eliminated that item has expanded our
>> community and user base to many people who never tried PostgreSQL before.
>
> So refresh us again what the top five were?
Well, it's with the minutes of the 2007 developer meeting ... *if*
anyone can find that on the wiki. Someday we need to fix wiki search.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
> Well, it's with the minutes of the 2007 developer meeting ... *if*
> anyone can find that on the wiki. Someday we need to fix wiki search.
Aha found it, no thanks to wiki search, and no thanks to Spotlight either.
So, my memory was wrong. Actually, they reported having a one-click
install as the #1 issue, not the #3 issue:
1. Easy Install
2. Simple, low-overhead replication
3. Upgrade-in-place
4. Administration & monitoring
5. Driver quality/maintenance
... it's really nice the number of the above issues we've knocked out
since 2007.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sat, Feb 26, 2011 at 1:39 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> Well, it's with the minutes of the 2007 developer meeting ... *if* >> anyone can find that on the wiki. Someday we need to fix wiki search. > > Aha found it, no thanks to wiki search, and no thanks to Spotlight either. > > So, my memory was wrong. Actually, they reported having a one-click > install as the #1 issue, not the #3 issue: > > 1. Easy Install > > 2. Simple, low-overhead replication > > 3. Upgrade-in-place > > 4. Administration & monitoring > > 5. Driver quality/maintenance > > ... it's really nice the number of the above issues we've knocked out > since 2007. Link? :) -selena -- http://chesnok.com
>> ... it's really nice the number of the above issues we've knocked out
>> since 2007.
>
> Link? :)
What link? I *still* can't find the minutes on the wiki.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh@agliodbs.com> wrote: > >>> ... it's really nice the number of the above issues we've knocked out >>> since 2007. >> >> Link? :) > > What link? I *still* can't find the minutes on the wiki. Ah, I thought you meant that you'd found this on the wiki. I don't see any information about PgCon 2007 on the wiki, so it may not be the fault of search. -selena -- http://chesnok.com
On 2/26/11 1:51 PM, Selena Deckelmann wrote:
> On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>>> ... it's really nice the number of the above issues we've knocked out
>>>> since 2007.
>>> Link? :)
>> What link? I *still* can't find the minutes on the wiki.
>
> Ah, I thought you meant that you'd found this on the wiki.
>
> I don't see any information about PgCon 2007 on the wiki, so it may
> not be the fault of search.
Can't find them on my HDD either. Did we not do minutes for the first
meeting?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Sat, Feb 26, 2011 at 1:54 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 2/26/11 1:51 PM, Selena Deckelmann wrote: >> On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh@agliodbs.com> wrote: >>>>> ... it's really nice the number of the above issues we've knocked out >>>>> since 2007. >>>> Link? :) >>> What link? I *still* can't find the minutes on the wiki. >> >> Ah, I thought you meant that you'd found this on the wiki. >> >> I don't see any information about PgCon 2007 on the wiki, so it may >> not be the fault of search. > > Can't find them on my HDD either. Did we not do minutes for the first > meeting? I wasn't there, so don't know. :) -selena -- http://chesnok.com
Josh Berkus wrote: > > > Well, it's with the minutes of the 2007 developer meeting ... *if* > > anyone can find that on the wiki. Someday we need to fix wiki search. > > Aha found it, no thanks to wiki search, and no thanks to Spotlight either. > > So, my memory was wrong. Actually, they reported having a one-click > install as the #1 issue, not the #3 issue: > > 1. Easy Install > > 2. Simple, low-overhead replication > > 3. Upgrade-in-place > > 4. Administration & monitoring > > 5. Driver quality/maintenance > > ... it's really nice the number of the above issues we've knocked out > since 2007. Wow, that is amazing, like we actually have a plan. ;-) LOL -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On lör, 2011-02-26 at 13:54 -0800, Josh Berkus wrote: > On 2/26/11 1:51 PM, Selena Deckelmann wrote: > > On Sat, Feb 26, 2011 at 1:46 PM, Josh Berkus <josh@agliodbs.com> wrote: > >>>> ... it's really nice the number of the above issues we've knocked out > >>>> since 2007. > >>> Link? :) > >> What link? I *still* can't find the minutes on the wiki. > > > > Ah, I thought you meant that you'd found this on the wiki. > > > > I don't see any information about PgCon 2007 on the wiki, so it may > > not be the fault of search. > > Can't find them on my HDD either. Did we not do minutes for the first > meeting? Yes: http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting But what you are looking for is here: http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#Top_Adoption_Issues
> Yes: http://wiki.postgresql.org/wiki/PgCon_2008_Developer_Meeting > > But what you are looking for is here: > http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#Top_Adoption_Issues Was 2008 the first meeting? Huh. Yeah, I suppose so. So I must have introduced the top 5 items in an unofficial meeting in 2007, because I did so when we originally commissioned the research. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
Le 26/02/2011 22:39, Josh Berkus a écrit : > >> Well, it's with the minutes of the 2007 developer meeting ... *if* >> anyone can find that on the wiki. Someday we need to fix wiki search. > > Aha found it, no thanks to wiki search, and no thanks to Spotlight either. > > So, my memory was wrong. Actually, they reported having a one-click > install as the #1 issue, not the #3 issue: > > 1. Easy Install > > 2. Simple, low-overhead replication > > 3. Upgrade-in-place > > 4. Administration & monitoring > > 5. Driver quality/maintenance > > ... it's really nice the number of the above issues we've knocked out > since 2007. > yes... it would be interesting to know what are the 5 next challenges :) -- damien clochard dalibo.com | dalibo.org
> yes... it would be interesting to know what are the 5 next challenges :)
I don't have an analyst budget anymore. Although ...
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On 02/28/11 22:58, damien clochard wrote: > Le 26/02/2011 22:39, Josh Berkus a écrit : >> >>> Well, it's with the minutes of the 2007 developer meeting ... *if* >>> anyone can find that on the wiki. Someday we need to fix wiki search. >> >> Aha found it, no thanks to wiki search, and no thanks to Spotlight either. >> >> So, my memory was wrong. Actually, they reported having a one-click >> install as the #1 issue, not the #3 issue: >> >> 1. Easy Install >> >> 2. Simple, low-overhead replication >> >> 3. Upgrade-in-place >> >> 4. Administration & monitoring >> >> 5. Driver quality/maintenance >> >> ... it's really nice the number of the above issues we've knocked out >> since 2007. >> > > yes... it would be interesting to know what are the 5 next challenges :) 1. To get rid of nasty CSTRING type 2. To get rid of the difference between TEXT and BYTEA (and then get rid of the BYTEA) 3. To make TIMESTAMPTZ useful by introducing proper type cast TIMESTAMPTZ to TIMESTAMP 4. Introduce a pair of preferences (server_timezone, client_timezone) instead of a single pref (timezone) (and use their values similar as (client_encoding, server_encoding) are used) 5. N/A the Postrgesql is too good for me to compose 5th challenge. but these four are too disturbing and irrational. example SELECT 'epoch'::TIMESTAMP = 'epoch'::TIMESTAMPTZ::TIMESTAMP; OOPS! we have TWO DIFFERENT EPOCHS!!!
On 1 March 2011 06:39, silly sad <sad@bestmx.ru> wrote: > On 02/28/11 22:58, damien clochard wrote: >> Le 26/02/2011 22:39, Josh Berkus a écrit : >>> >>>> Well, it's with the minutes of the 2007 developer meeting ... *if* >>>> anyone can find that on the wiki. Someday we need to fix wiki search. >>> >>> Aha found it, no thanks to wiki search, and no thanks to Spotlight either. >>> >>> So, my memory was wrong. Actually, they reported having a one-click >>> install as the #1 issue, not the #3 issue: >>> >>> 1. Easy Install >>> >>> 2. Simple, low-overhead replication >>> >>> 3. Upgrade-in-place >>> >>> 4. Administration & monitoring >>> >>> 5. Driver quality/maintenance >>> >>> ... it's really nice the number of the above issues we've knocked out >>> since 2007. >>> >> >> yes... it would be interesting to know what are the 5 next challenges :) > > 1. To get rid of nasty CSTRING type > 2. To get rid of the difference between TEXT and BYTEA (and then get rid > of the BYTEA) > 3. To make TIMESTAMPTZ useful by introducing proper type cast > TIMESTAMPTZ to TIMESTAMP > 4. Introduce a pair of preferences (server_timezone, client_timezone) > instead of a single pref (timezone) (and use their values similar as > (client_encoding, server_encoding) are used) > 5. N/A > > the Postrgesql is too good for me to compose 5th challenge. > but these four are too disturbing and irrational. > > example > > SELECT 'epoch'::TIMESTAMP = 'epoch'::TIMESTAMPTZ::TIMESTAMP; > > OOPS! we have TWO DIFFERENT EPOCHS!!! No, you have one which doesn't apply the timezone difference, and one which does. So if you're UTC+1, you end up with: '1970-01-01 00:00:00' = '1970-01-01 01:00:00' -- false When you cast this timestamp with timezone to a normal timestamp, it retains the time, but not the timezone. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
* silly sad: > 2. To get rid of the difference between TEXT and BYTEA (and then get rid > of the BYTEA) The TEXT/BYTEA distinction is used by several interface libraries to create appropriate programming language types. What might work, though, is to get rid of BYTEA escaping in the wire protocol (optionally, for backwards compatibility), and support NUL characters in TEXT. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Excerpts from silly sad's message of mar mar 01 03:39:35 -0300 2011: > 3. To make TIMESTAMPTZ useful by introducing proper type cast > TIMESTAMPTZ to TIMESTAMP I think this is the AT TIME ZONE operator (works both ways). > 4. Introduce a pair of preferences (server_timezone, client_timezone) > instead of a single pref (timezone) (and use their values similar as > (client_encoding, server_encoding) are used) I think server_timezone is hardwired as GMT. client_timezone is our current timezone setting. I don't see the point in having server_timezone be configurable ... is there one? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Sad,
Thanks for the wishlist, but this doesn't seem likely to be the top
priorities of new adopters. ;-)
> 1. To get rid of nasty CSTRING type
> 2. To get rid of the difference between TEXT and BYTEA (and then get rid
> of the BYTEA)
> 3. To make TIMESTAMPTZ useful by introducing proper type cast
> TIMESTAMPTZ to TIMESTAMP
Why are you using Timestamp-no-tz at all? I was thinking we should
change the default ...
> 4. Introduce a pair of preferences (server_timezone, client_timezone)
> instead of a single pref (timezone) (and use their values similar as
> (client_encoding, server_encoding) are used)
When would server_timezone be used?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > 1. Easy Install > 2. Simple, low-overhead replication > 3. Upgrade-in-place > 4. Administration & monitoring > 5. Driver quality/maintenance >> ... it's really nice the number of the above issues we've knocked out >> since 2007. > > yes... it would be interesting to know what are the 5 next challenges :) I think we haven't finished these five yet! :) > 1. Easy Install Solved, I suppose. We've always had "yum install" and friends, and now we have the EDB 1-click installer. The only fly in the ointment is the recent crap Debian pulled (yes, what they did was correct, but it should have been handled much better). Hopefully that will be solved soon with some better (and better licensed) supporting software. So this one is done. > 2. Simple, low-overhead replication Great progress here with hot standby which satisfies a great number of replication needs with very low overhead. I would not call it "simple" yet, but there are some tools out there that are attempting to fix this. Sometimes you need more than hot standby of course, and none of Bucardo, Slony, or Londiste are simple or low overhead. To be fair, however, I wonder how simple and low overhead some of the other RDBMSs solutions are. This one is mostly done. > 3. Upgrade-in-place Big success and big fail here. pg_upgrade goes a long, long way towards something better than pg_dump|psql, but it's not a true upgrade-in-place, where I can point my Postgres X+1 at my Postgres X data directory and have it all work. We need to catch up with Oracle on this. Halfway done. > 4. Administration & monitoring This is a pretty vague and wide-ranging topic, so it's hard to address. We do have a slew of administration GUIs, and a bunch of monitoring tools, but especially the latter need some work. Would be nice if these bullet points were broken down a little further with some actual specific complaints or ideas. Any chance of that, Josh? > 5. Driver quality/maintenance Also a little vague - which drivers? Certainly most of the major languages have decent drivers now. I think the Perl one is pretty good ;). PHP and Ruby are much improved in the last few years, and the most problematic one, Python, is getting better (and finally winnowing the choices as well). The maintenance is probably still an issue. Certainly there is a very small number of people taking care of each driver, and no single company (e.g. EDB) stepping up to dedicate a group of people to the care of feeding of a driver. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201103012252 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk1tv7EACgkQvJuQZxSWSsh9qwCfciRmJ2kLiHu0npG/TLyTa88N wYQAoLVNWwOBEQ1YaAUbEIucks8VKqYv =6v06 -----END PGP SIGNATURE-----
On Tue, Mar 1, 2011 at 10:55 PM, Greg Sabino Mullane <greg@turnstep.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > >> 1. Easy Install >> 2. Simple, low-overhead replication >> 3. Upgrade-in-place >> 4. Administration & monitoring >> 5. Driver quality/maintenance > >>> ... it's really nice the number of the above issues we've knocked out >>> since 2007. >> >> yes... it would be interesting to know what are the 5 next challenges :) > > I think we haven't finished these five yet! :) > >> 1. Easy Install > > Solved, I suppose. We've always had "yum install" and friends, and now > we have the EDB 1-click installer. The only fly in the ointment is > the recent crap Debian pulled (yes, what they did was correct, but > it should have been handled much better). Hopefully that will be solved > soon with some better (and better licensed) supporting software. > So this one is done. > >> 2. Simple, low-overhead replication > > Great progress here with hot standby which satisfies a great number > of replication needs with very low overhead. I would not call it > "simple" yet, but there are some tools out there that are attempting > to fix this. Sometimes you need more than hot standby of course, and > none of Bucardo, Slony, or Londiste are simple or low overhead. To be > fair, however, I wonder how simple and low overhead some of the other > RDBMSs solutions are. This one is mostly done. > You're much more optimistic than I am about this. Most of the other databases offer built in solutions that are quite a bit more flexible than what pg offers, and I don't see any changes to that on the horizon. See Haas' recent blog post on the topic for some limitations we aren't trying to solve. I think we'll have to embrace statement based replication at some point, but I know a lot of people are pretty against the idea. >> 3. Upgrade-in-place > > Big success and big fail here. pg_upgrade goes a long, long way towards > something better than pg_dump|psql, but it's not a true upgrade-in-place, > where I can point my Postgres X+1 at my Postgres X data directory and > have it all work. We need to catch up with Oracle on this. Halfway done. > Yeah; other things like being to replicate across versions are also something a lot of people would like to see. I think it's probably technically doable, although again I don't see anyone interested in working on it. >> 4. Administration & monitoring > > This is a pretty vague and wide-ranging topic, so it's hard to address. > We do have a slew of administration GUIs, and a bunch of monitoring > tools, but especially the latter need some work. Would be nice if these > bullet points were broken down a little further with some actual > specific complaints or ideas. Any chance of that, Josh? > Yeah, I think part of the issue here is either a lack of integration with "enterprisy" tools, or no really slick GUI of our own. (With apologies to pgadmin, but people coming from things like oem or sql server manager often find it very lacking) >> 5. Driver quality/maintenance > > Also a little vague - which drivers? Certainly most of the major languages > have decent drivers now. I think the Perl one is pretty good ;). PHP > and Ruby are much improved in the last few years, and the most problematic > one, Python, is getting better (and finally winnowing the choices as well). > > The maintenance is probably still an issue. Certainly there is a very > small number of people taking care of each driver, and no single company > (e.g. EDB) stepping up to dedicate a group of people to the care of > feeding of a driver. > Yeah, I think a number of these could use someone with a more dedicated interest in keeping them up to date with the main product line. Also you left out ODBC, which afaik is still a bit hard for most people to get moving with. Robert Treat http://www.xzilla.net
On Mar 2 2011, Josh Berkus wrote: >Sad, > >Thanks for the wishlist, but this doesn't seem likely to be the top >priorities of new adopters. ;-) > >> 1. To get rid of nasty CSTRING type >> 2. To get rid of the difference between TEXT and BYTEA (and then get rid >> of the BYTEA) >> 3. To make TIMESTAMPTZ useful by introducing proper type cast >> TIMESTAMPTZ to TIMESTAMP > >Why are you using Timestamp-no-tz at all? I was thinking we should >change the default ... Why did u introduced it? >> 4. Introduce a pair of preferences (server_timezone, client_timezone) >> instead of a single pref (timezone) (and use their values similar as >> (client_encoding, server_encoding) are used) > >When would server_timezone be used? > >
On Mar 1 2011, Alvaro Herrera wrote: >Excerpts from silly sad's message of mar mar 01 03:39:35 -0300 2011: > >> 3. To make TIMESTAMPTZ useful by introducing proper type cast >> TIMESTAMPTZ to TIMESTAMP > >I think this is the AT TIME ZONE operator (works both ways). > >> 4. Introduce a pair of preferences (server_timezone, client_timezone) >> instead of a single pref (timezone) (and use their values similar as >> (client_encoding, server_encoding) are used) > >I think server_timezone is hardwired as GMT. client_timezone is our >current timezone setting. I don't see the point in having >server_timezone be configurable ... is there one? GMT? let it be. i only ask u to USE IT while casting ::TIMESTAMPTZ::TIMESTAMP (instead of dropping TZ information)
Excerpts from sad's message of mié mar 02 10:23:53 -0300 2011: > On Mar 2 2011, Josh Berkus wrote: > >> 3. To make TIMESTAMPTZ useful by introducing proper type cast > >> TIMESTAMPTZ to TIMESTAMP > > > >Why are you using Timestamp-no-tz at all? I was thinking we should > >change the default ... > > Why did u introduced it? The standard requires the current behavior. It's not going to change. It changed in 7.1 or so. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Excerpts from sad's message of mié mar 02 10:35:59 -0300 2011: > On Mar 1 2011, Alvaro Herrera wrote: > > >Excerpts from silly sad's message of mar mar 01 03:39:35 -0300 2011: > >I think this is the AT TIME ZONE operator (works both ways). > > > >> 4. Introduce a pair of preferences (server_timezone, client_timezone) > >> instead of a single pref (timezone) (and use their values similar as > >> (client_encoding, server_encoding) are used) > > > >I think server_timezone is hardwired as GMT. client_timezone is our > >current timezone setting. I don't see the point in having > >server_timezone be configurable ... is there one? > > GMT? let it be. > i only ask u to USE IT while casting ::TIMESTAMPTZ::TIMESTAMP > (instead of dropping TZ information) As I said in my previous response, don't cast. Use AT TIME ZONE. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 26 February 2011 21:35, Josh Berkus <josh@agliodbs.com> wrote: > > Someday we need to fix wiki search. > http://www.mediawiki.org/wiki/Extension:MWSearch using a Lucene-search 2.1 daemon. That is what wikipedia and us (OpenStreetMap) use. Regards Grant Part of OSM Sysadmin team.
On Wed, Mar 2, 2011 at 17:25, Grant Slater <postgresql@firefishy.com> wrote: > On 26 February 2011 21:35, Josh Berkus <josh@agliodbs.com> wrote: >> >> Someday we need to fix wiki search. >> > > http://www.mediawiki.org/wiki/Extension:MWSearch > using a Lucene-search 2.1 daemon. > > That is what wikipedia and us (OpenStreetMap) use. Gah, yet another piece of software :-( What do we use *now*? Does it actually use tsearch, or something else? It's not like we need lucene for performance... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 03/02/11 17:07, Alvaro Herrera wrote: > Excerpts from sad's message of mié mar 02 10:23:53 -0300 2011: >> On Mar 2 2011, Josh Berkus wrote: > >>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast >>>> TIMESTAMPTZ to TIMESTAMP >>> >>> Why are you using Timestamp-no-tz at all? I was thinking we should >>> change the default ... >> >> Why did u introduced it? > > The standard requires the current behavior. It's not going to change. > It changed in 7.1 or so. > does standard require to have TWO DIFFERENT EPOCHS? SELECT 'epoch'::TIMESTAMPTZ, 'epoch'::TIMESTAMP;
> What do we use *now*? Does it actually use tsearch, or something else?
> It's not like we need lucene for performance...
If it's using tsearch, it's not creating the index correctly. Searches
on words which are *all over* a page don't turn up that page.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >>On 26 February 2011 21:35, Josh Berkus <josh@agliodbs.com> wrote: >> >> Someday we need to fix wiki search. > > http://www.mediawiki.org/wiki/Extension:MWSearch > using a Lucene-search 2.1 daemon. > > That is what wikipedia and us (OpenStreetMap) use. What exactly is broken about it? From what I recall, Josh's search failed because the page did not exist (no notes put on wiki from the 2007 meeting). If there is a problem, I'd rather continue to eat our own tsearch dogfood and fix it rather than go with yet another piece of technology. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201103032222 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk1wWwsACgkQvJuQZxSWSsjE+wCglkbPzLA6SS9FYKEL2tLaK0eU 0IkAoKYTpiajC+pvbCPFw+Lb8Jr2pxmj =JK1X -----END PGP SIGNATURE-----
Robert Treat wrote: > >> 2. Simple, low-overhead replication > > > > Great progress here with hot standby which satisfies a great number > > of replication needs with very low overhead. I would not call it > > "simple" yet, but there are some tools out there that are attempting > > to fix this. Sometimes you need more than hot standby of course, and > > none of Bucardo, Slony, or Londiste are simple or low overhead. To be > > fair, however, I wonder how simple and low overhead some of the other > > RDBMSs solutions are. This one is mostly done. > > > > You're much more optimistic than I am about this. Most of the other > databases offer built in solutions that are quite a bit more flexible > than what pg offers, and I don't see any changes to that on the > horizon. See Haas' recent blog post on the topic for some limitations > we aren't trying to solve. I think we'll have to embrace statement > based replication at some point, but I know a lot of people are pretty > against the idea. I hope people are not confusing logical row replication with statement-based (SQL query) replication. Robert was talking about the former, and the later is fraught with problems. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Alvaro Herrera wrote:
> Excerpts from sad's message of mié mar 02 10:23:53 -0300 2011:
> > On Mar 2 2011, Josh Berkus wrote:
>
> > >> 3. To make TIMESTAMPTZ useful by introducing proper type cast
> > >> TIMESTAMPTZ to TIMESTAMP
> > >
> > >Why are you using Timestamp-no-tz at all? I was thinking we should
> > >change the default ...
> >
> > Why did u introduced it?
>
> The standard requires the current behavior. It's not going to change.
> It changed in 7.1 or so.
And we document why the default is so odd:
http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES
Note: The SQL standard requires that writing just timestamp be
equivalent to timestamp without time zone, and PostgreSQL honors that
behavior. (Releases prior to 7.3 treated it as timestamp with time
zone.)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On 03/10/11 19:01, Bruce Momjian wrote: > Alvaro Herrera wrote: >> Excerpts from sad's message of mié mar 02 10:23:53 -0300 2011: >>> On Mar 2 2011, Josh Berkus wrote: >> >>>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast >>>>> TIMESTAMPTZ to TIMESTAMP >>>> >>>> Why are you using Timestamp-no-tz at all? I was thinking we should >>>> change the default ... >>> >>> Why did u introduced it? >> >> The standard requires the current behavior. It's not going to change. >> It changed in 7.1 or so. > > And we document why the default is so odd: > > http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES > > Note: The SQL standard requires that writing just timestamp be > equivalent to timestamp without time zone, and PostgreSQL honors that > behavior. (Releases prior to 7.3 treated it as timestamp with time > zone.) do you document why 'epoch'::timestamp is not the true 'epoch' unless timezone is not GMT? if you mention any timestamp except 'epoch' it will be interpreted correctly taking in account timezone setting.
silly sad wrote: > On 03/10/11 19:01, Bruce Momjian wrote: > > Alvaro Herrera wrote: > >> Excerpts from sad's message of mi? mar 02 10:23:53 -0300 2011: > >>> On Mar 2 2011, Josh Berkus wrote: > >> > >>>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast > >>>>> TIMESTAMPTZ to TIMESTAMP > >>>> > >>>> Why are you using Timestamp-no-tz at all? I was thinking we should > >>>> change the default ... > >>> > >>> Why did u introduced it? > >> > >> The standard requires the current behavior. It's not going to change. > >> It changed in 7.1 or so. > > > > And we document why the default is so odd: > > > > http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES > > > > Note: The SQL standard requires that writing just timestamp be > > equivalent to timestamp without time zone, and PostgreSQL honors that > > behavior. (Releases prior to 7.3 treated it as timestamp with time > > zone.) > > do you document why 'epoch'::timestamp is not the true 'epoch' unless > timezone is not GMT? > > if you mention any timestamp except 'epoch' it will be interpreted > correctly taking in account timezone setting. Well, 'epoch' clearly is a point in time with the hour being midnight at GMT, so I don't see a problem with epoch making such an adjustment: test=> select 'epoch'::timestamp ; timestamp --------------------- 1970-01-01 00:00:00 (1 row) test=> select 'epoch'::timestamptz; timestamptz ------------------------ 1969-12-31 19:00:00-05 (1 row) However, a text string behaves the same: test=> select '1970-01-01 00:00:00'::timestamp; timestamp --------------------- 1970-01-01 00:00:00 (1 row) test=> select '1970-01-01 00:00:00'::timestamptz; timestamptz ------------------------ 1970-01-01 00:00:00-05 (1 row) Notice the "-05". I would argue that 'epoch' has a predefined timezone. We don't document this because it has never been mentioned before and no one has mentioned they were surprised by the behavior. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 03/10/11 19:45, Bruce Momjian wrote: > silly sad wrote: >> On 03/10/11 19:01, Bruce Momjian wrote: >>> Alvaro Herrera wrote: >>>> Excerpts from sad's message of mi? mar 02 10:23:53 -0300 2011: >>>>> On Mar 2 2011, Josh Berkus wrote: >>>> >>>>>>> 3. To make TIMESTAMPTZ useful by introducing proper type cast >>>>>>> TIMESTAMPTZ to TIMESTAMP >>>>>> >>>>>> Why are you using Timestamp-no-tz at all? I was thinking we should >>>>>> change the default ... >>>>> >>>>> Why did u introduced it? >>>> >>>> The standard requires the current behavior. It's not going to change. >>>> It changed in 7.1 or so. >>> >>> And we document why the default is so odd: >>> >>> http://www.postgresql.org/docs/9.0/static/datatype-datetime.html#DATATYPE-TIMEZONES >>> >>> Note: The SQL standard requires that writing just timestamp be >>> equivalent to timestamp without time zone, and PostgreSQL honors that >>> behavior. (Releases prior to 7.3 treated it as timestamp with time >>> zone.) >> >> do you document why 'epoch'::timestamp is not the true 'epoch' unless >> timezone is not GMT? >> >> if you mention any timestamp except 'epoch' it will be interpreted >> correctly taking in account timezone setting. > > Well, 'epoch' clearly is a point in time with the hour being midnight at > GMT, so I don't see a problem with epoch making such an adjustment: great! the flexible epoch! when do want to point an epoch to? just set timezone and enjoy.
On 03/10/2011 08:53 AM, silly sad wrote: >> >> Well, 'epoch' clearly is a point in time with the hour being midnight at >> GMT, so I don't see a problem with epoch making such an adjustment: > > > great! the flexible epoch! > > when do want to point an epoch to? > just set timezone and enjoy. > I am not sure what your point is. The epoch being used is just one of many that could have been used, see link below. So by definition the term epoch is flexible. The Postgres project has chosen a particular value for 'epoch' as explained in the docs. This 'epoch' is a special datetime value pinned to a point in time(as Bruce mentioned). All adding a time zone does is translate the GMT point in time to the time zone point in time. They are the same time. http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Computing -- Adrian Klaver adrian.klaver@gmail.com
On 03/10/11 20:07, Adrian Klaver wrote:
> On 03/10/2011 08:53 AM, silly sad wrote:
>
>
>>>
>>> Well, 'epoch' clearly is a point in time with the hour being midnight at
>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>
>>
>> great! the flexible epoch!
>>
>> when do want to point an epoch to?
>> just set timezone and enjoy.
>>
>
> I am not sure what your point is.
my point is:
SELECT extract('epoch' from 'epoch'::timestamp);
On 03/10/2011 09:15 AM, silly sad wrote:
> On 03/10/11 20:07, Adrian Klaver wrote:
>> On 03/10/2011 08:53 AM, silly sad wrote:
>>
>>
>>>>
>>>> Well, 'epoch' clearly is a point in time with the hour being midnight at
>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>
>>>
>>> great! the flexible epoch!
>>>
>>> when do want to point an epoch to?
>>> just set timezone and enjoy.
>>>
>>
>> I am not sure what your point is.
>
> my point is:
>
> SELECT extract('epoch' from 'epoch'::timestamp);
Simplest explanation is you are comparing a time zone aware datetime
'epoch' to an unaware one 'epoch'::timezone. The second one, since it
is not anchored to a time zone is taken to be local time and the result
you get is the interval in seconds between the two.
Try:
test=> SELECT extract(EPOCH from 'epoch'::timestamptz);
date_part
-----------
0
or
test=> SELECT extract(EPOCH from 'epoch'::timestamp at time zone 'utc');
date_part
-----------
0
--
Adrian Klaver
adrian.klaver@gmail.com
On 03/10/11 20:48, Adrian Klaver wrote:
> On 03/10/2011 09:15 AM, silly sad wrote:
>> On 03/10/11 20:07, Adrian Klaver wrote:
>>> On 03/10/2011 08:53 AM, silly sad wrote:
>>>
>>>
>>>>>
>>>>> Well, 'epoch' clearly is a point in time with the hour being
>>>>> midnight at
>>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>>
>>>>
>>>> great! the flexible epoch!
>>>>
>>>> when do want to point an epoch to?
>>>> just set timezone and enjoy.
>>>>
>>>
>>> I am not sure what your point is.
>>
>> my point is:
>>
>> SELECT extract('epoch' from 'epoch'::timestamp);
>
> Simplest explanation is you are comparing a time zone aware datetime
> 'epoch' to an unaware one 'epoch'::timezone. The second one, since it
> is not anchored to a time zone is taken to be local time and the result
> you get is the interval in seconds between the two.
(1) do u really believe in this?
(2) why didn't u try the select i wrote?
On 03/10/2011 09:57 AM, silly sad wrote:
> On 03/10/11 20:48, Adrian Klaver wrote:
>> On 03/10/2011 09:15 AM, silly sad wrote:
>>> On 03/10/11 20:07, Adrian Klaver wrote:
>>>> On 03/10/2011 08:53 AM, silly sad wrote:
>>>>
>>>>
>>>>>>
>>>>>> Well, 'epoch' clearly is a point in time with the hour being
>>>>>> midnight at
>>>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>>>
>>>>>
>>>>> great! the flexible epoch!
>>>>>
>>>>> when do want to point an epoch to?
>>>>> just set timezone and enjoy.
>>>>>
>>>>
>>>> I am not sure what your point is.
>>>
>>> my point is:
>>>
>>> SELECT extract('epoch' from 'epoch'::timestamp);
>>
>> Simplest explanation is you are comparing a time zone aware datetime
>> 'epoch' to an unaware one 'epoch'::timezone. The second one, since it
>> is not anchored to a time zone is taken to be local time and the result
>> you get is the interval in seconds between the two.
>
> (1) do u really believe in this?
> (2) why didn't u try the select i wrote?
Yes
I did.
--
Adrian Klaver
adrian.klaver@gmail.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > (1) do u really believe in this? > (2) why didn't u try the select i wrote? Can we take this to -general please? Or better yet, let the thread die? - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201103101307 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk15E2AACgkQvJuQZxSWSsgN0ACgm3eNwlXP+63vRx74mIk9RY6s rdUAn1lUknijWxxP0S7cANoKldTVEhPq =F24a -----END PGP SIGNATURE-----
On 03/10/11 20:52, Adrian Klaver wrote:
> On 03/10/2011 09:57 AM, silly sad wrote:
>> On 03/10/11 20:48, Adrian Klaver wrote:
>>> On 03/10/2011 09:15 AM, silly sad wrote:
>>>> On 03/10/11 20:07, Adrian Klaver wrote:
>>>>> On 03/10/2011 08:53 AM, silly sad wrote:
>>>>>
>>>>>
>>>>>>>
>>>>>>> Well, 'epoch' clearly is a point in time with the hour being
>>>>>>> midnight at
>>>>>>> GMT, so I don't see a problem with epoch making such an adjustment:
>>>>>>
>>>>>>
>>>>>> great! the flexible epoch!
>>>>>>
>>>>>> when do want to point an epoch to?
>>>>>> just set timezone and enjoy.
>>>>>>
>>>>>
>>>>> I am not sure what your point is.
>>>>
>>>> my point is:
>>>>
>>>> SELECT extract('epoch' from 'epoch'::timestamp);
>>>
>>> Simplest explanation is you are comparing a time zone aware datetime
>>> 'epoch' to an unaware one 'epoch'::timezone. The second one, since it
>>> is not anchored to a time zone is taken to be local time and the result
>>> you get is the interval in seconds between the two.
>>
>> (1) do u really believe in this?
>> (2) why didn't u try the select i wrote?
>
> Yes
> I did.
do u think the 'epoch' of 'epoch' should not be 0 ?