Re: [GENERAL] Oracle and Postgresql

2008/9/9 0123 zyxw <0123zyxw@gmail.com>:
> Kevin Hunter wrote:
>>
>> 1. Oracle was "first", and has vendor lock-in momentum.
>> 2. Oracle ...speed/performance/concurrency...
>> 3. Oracle has application lock-in as well. ...
>> 4. Oracle is company-backed, so there is ostensibly "someone to blame"..
>> 5. ... individuals ... may prefer it *because* it's expensive...
>> 6. Mucho better advertising to the right people....
>> 7. ...print-version...
>
> 8. Oracle salespeople will help B2B software companies help sell
> and bid on larger oracle-based products and projects.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

1. Maybe ...
2. Of course, like others DBMS, but how many people knows how it's
configure? Are you configure ORACLE DBMS? 1000+ strange parameters and
don't tell me that they are well document. The same with Oracle Apps.
3. Are you kidding? Are you work with Oracle AS, ifs, cmsdk etc? I've
never seen so "good", "fast" and "scalable" software.
4. Software "AS IS" - no comment.
5. ? Lets look:
with Oracle:
App = Oracle licences + yours work = X (and pay for everything - help,
support etc.),
with PostgreSQL:
App = 0 for licences + work = Y,
if X=Y who has more profits?

6. Agree :-((( Oracle marketing is realy the best.
7. ?
8. As I say in 5. - pay for everything - if you are money everybady
helps you (even I, and if you pay 1.000.000 $ I say Oracle is the
best, like other Oracle experts).

Regards,
Blazej

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [BUGS] BUG #4416: Between operator is not working as expected

On Sat, 13 Sep 2008, Murali wrote:

>
> The following bug has been logged online:
>
> Bug reference: 4416
> Logged by: Murali
> Email address: muralidoss@rediffmail.com
> PostgreSQL version: 8.2.6
> Operating system: Linux
> Description: Between operator is not working as expected
> Details:
>
> Actually sql works fine in solaris with 8.2.5 postgresql version but same
> sql query is not working in linux.
>
> fyi...both the database in linux and solaris are having similar structure
> and data too.
>
> Here is the query i am try to execute
>
> select * from table1 where col1 between 'SM' and 'SM~';
>
> Please guide me

My guess would be that the behavior of the collations on the two machines
are different. It looks like you're expecting "C" style byte order
comparisons, but your linux box probably is using a different collation.
What does "show LC_COLLATE;" give you from psql to both databases?

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [pgsql-www] event removed

On Sat, Sep 13, 2008 at 12:36:34PM -0400, Robert Treat wrote:
> Hi folks,
>
> I've "unapproved" the event "Workshop with Bruce Momjian at São Paulo" (you
> can view it at http://www.postgresql.org/about/event.715 untill the next site
> refresh) since Bruce has canceled his attendence. If it is planned to go on
> anyway, please let us know how we should change the wording (or just resubmit
> it with new info). Thanks.

There's some possibility I may be pinch hitting on that one. I should
find out by Monday.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[BUGS] BUG #4416: Between operator is not working as expected

The following bug has been logged online:

Bug reference: 4416
Logged by: Murali
Email address: muralidoss@rediffmail.com
PostgreSQL version: 8.2.6
Operating system: Linux
Description: Between operator is not working as expected
Details:

Actually sql works fine in solaris with 8.2.5 postgresql version but same
sql query is not working in linux.

fyi...both the database in linux and solaris are having similar structure
and data too.

Here is the query i am try to execute

select * from table1 where col1 between 'SM' and 'SM~';

Please guide me

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Yo puedo registrar el dominio sin ningun problema. Sin embargo, me
preocupa la titularidad del mismo.

Puede quedar a mi nombre sin problema y mas adelante cederlo a quien
quiera hacerse cargo u organizacion que sugieran. Si alguien tiene una
sugerencia mejor me escriben y lo discutimos sin problema. Quisiera
hacer esto el lunes a mas tardar para sacarme el tema de encima porque
tengo compromisos durante la semana y probablemente ya no pueda
dedicarle el tiempo suficiente.

Necesitaria que me digan los servidores de nombres de dominio (DNS)
sobre los cuales quieren que delege el dominio. El tramite lo haria en
Godaddy.com, alguien tiene una alternativa mejor? Tengo cuenta alli y
conozco el servicio. Pero escucho sugerencias u votaciones de la
comunidad al respecto. Creo que alguien se iba a ocupar del hosting,
asi que espero el contacto de esa persona por las cuestiones tecnicas.

Saludos,
Guido Barosio

2008/9/13 Ricardo Mendoza <pgsqlcol@gmail.com>:
> Saludos Guido,
>
> El dominio es necesario y seria oportuno si puedes hacer tu donacion
> para arrancar con la pagina web lo antes posible. La pagina alojara al
> psdp-es y todo lo que sea necesario para coordinar mejor el trabajo de
> traduccion, obviamente si surge algo en el camino lo iremos
> integrando.
>
> Creo que personalmente he dado alguna muestra de interes, no quiero
> personalizar esto, pero yo estoy interesado en sacar adelante esto y
> bueno le he puesto mucho de mi tiempo, para hacerlo real. asi que si
> podemos hablar de una persona que este al frente de nuevo en esta
> iniciativa, pudo levantar la mano sin temor y decir que he participado
> activamente. Tambien se encuentran obviamente y con mucha trayectoria
> Alvaro Herrera y Mario Gonzalez y otros, que segun como tengo
> entendido venian trabajando sobre la traducion, con la creacion del
> framework Webtranslate, que ha falta de un programador quedo sin
> soporte.
>
> Aprovecho la oportunidad para informar a la lista el cambio de mi
> nickname Moises Galan, por mi nombre real: Ricardo Mendoza, ya que al
> momento de abrir la cuenta no tuve la precaucion que lo hice con un
> nickname, esto con el fin de facilitar el intercambio de informacion y
> evitar confusiones a los diversos destinarios de mi cuenta de correo.
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [GENERAL] about partitioning

8><
> For some more info, I've given at least one presentation on the topic, which
> seems to be missing from the omniti site, but I've uploaded it to
> slideshare...
> http://www.slideshare.net/xzilla/postgresql-partitioning-pgcon-2007-presentation
>
> HTH.
>
8><

Very nice presentation. I have 2 additional questions:

(1) Are you testing INSERT/UPDATE performance when is only one rule
script for all partition tables?
(2) Are you using "SET constraint_exclusion = on;"?

Regards,
Blazej

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [pgsql-www] slow email

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

200.46.204.86 would be the mailing list queue itself ... if, for some reason,
the moderator of the list was offline for a few days, that would account for
the delay in seeing it on the lists ...

- --On Saturday, September 13, 2008 13:16:20 -0400 Kevin Hunter
<hunteke@earlham.edu> wrote:

> Hiya List,
>
> I've noted that some emails have started to come in mucho delayed via
> the lists. Here are the headers of an example email that exhibits this
> behavior. I received two copies, one directly a mere 9 seconds after it
> was sent, and the other (via the lists) took 6 days.
>
> The hold up seems to be at 200.46.204.86 .
>
> Any ideas, or log-clues?
>
> Kevin

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkjMOVoACgkQ4QvfyHIvDvNxtACfbbV3vRfqeFRcHiVEE7cphdqf
rnoAoLFjxnMsTkA+rQknySB5y9WcBK5G
=sGPZ
-----END PGP SIGNATURE-----

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Saludos Guido,

El dominio es necesario y seria oportuno si puedes hacer tu donacion
para arrancar con la pagina web lo antes posible. La pagina alojara al
psdp-es y todo lo que sea necesario para coordinar mejor el trabajo de
traduccion, obviamente si surge algo en el camino lo iremos
integrando.

Creo que personalmente he dado alguna muestra de interes, no quiero
personalizar esto, pero yo estoy interesado en sacar adelante esto y
bueno le he puesto mucho de mi tiempo, para hacerlo real. asi que si
podemos hablar de una persona que este al frente de nuevo en esta
iniciativa, pudo levantar la mano sin temor y decir que he participado
activamente. Tambien se encuentran obviamente y con mucha trayectoria
Alvaro Herrera y Mario Gonzalez y otros, que segun como tengo
entendido venian trabajando sobre la traducion, con la creacion del
framework Webtranslate, que ha falta de un programador quedo sin
soporte.

Aprovecho la oportunidad para informar a la lista el cambio de mi
nickname Moises Galan, por mi nombre real: Ricardo Mendoza, ya que al
momento de abrir la cuenta no tuve la precaucion que lo hice con un
nickname, esto con el fin de facilitar el intercambio de informacion y
evitar confusiones a los diversos destinarios de mi cuenta de correo.
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [PERFORM] Choosing a filesystem

On Fri, 12 Sep 2008, Merlin Moncure wrote:

> On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <gsmith@gregsmith.com> wrote:
>> On Fri, 12 Sep 2008, Guillaume Cottenceau wrote:
>>
>> That's the main thing, and nothing else you can do will accelerate that.
>> Without a useful write cache (which usually means RAM with a BBU), you'll at
>> best get about 100-200 write transactions per second for any one client, and
>> something like 500/second even with lots of clients (queued up transaction
>> fsyncs do get combined). Those numbers increase to several thousand per
>> second the minute there's a good caching controller in the mix.
>
> While this is correct, if heavy writing is sustained, especially on
> large databases, you will eventually outrun the write cache on the
> controller and things will start to degrade towards the slow case. So
> it's fairer to say that caching raid controllers burst up to several
> thousand per second, with a sustained write rate somewhat better than
> write-through but much worse than the burst rate.
>
> How fast things degrade from the burst rate depends on certain
> factors...how big the database is relative to the o/s read cache in
> the controller write cache, and how random the i/o is generally. One
> thing raid controllers are great at is smoothing bursty i/o during
> checkpoints for example.
>
> Unfortunately when you outrun cache on raid controllers the behavior
> is not always very pleasant...in at least one case I've experienced
> (perc 5/i) when the cache fills up the card decides to clear it before
> continuing. This means that if fsync is on, you get unpredictable
> random freezing pauses while the cache is clearing.

although for postgres the thing that you are doing the fsync on is the WAL
log file. that is a single (usually) contiguous file. As such it is very
efficiant to write large chunks of it. so while you will degrade from the
battery-only mode, the fact that the controller can flush many requests
worth of writes out to the WAL log at once while you fill the cache with
them one at a time is still a significant win.

David Lang

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Effects of setting linux block device readahead size

On Fri, 12 Sep 2008, James Mansion wrote:

> Scott Carey wrote:
>> Consumer drives will often read-ahead much more than server drives
>> optimized for i/o per second.
> ...
>> The Linux readahead setting is _definitely_ in the kernel, definitely uses
>> and fills the page cache, and from what I can gather, simply issues extra
>> I/O's to the hardware beyond the last one requested by an app in certain
>> situations. It does not make your I/O request larger, it just queues an
>> extra I/O following your request.
> So ... fiddling with settings in Linux is going to force read-ahead, but the
> read-ahead data will hit the controller cache and the system buffers.
>
> And the drives use their caches for cyclinder caching implicitly (maybe the
> SATA drives appear to preread more because the storage density per cylinder
> is higher?)..
>
> But is there any way for an OS or application to (portably) ask SATA, SAS or
> SCSI drives to read ahead more (or less) than their default and NOT return
> the data to the controller?
>
> I've never heard of such a thing, but I'm no expert in the command sets for
> any of this stuff.

I'm pretty sure that's not possible. the OS isn't supposed to even know
the internals of the drive.

David Lang

> James
>
>>
>> On Thu, Sep 11, 2008 at 12:54 PM, James Mansion
>> <james@mansionfamily.plus.com <mailto:james@mansionfamily.plus.com>> wrote:
>>
>> Greg Smith wrote:
>>
>> The point I was trying to make there is that even under
>> impossibly optimal circumstances, you'd be hard pressed to
>> blow out the disk's read cache with seek-dominated data even
>> if you read a lot at each seek point. That idea didn't make
>> it from my head into writing very well though.
>>
>> Isn't there a bigger danger in blowing out the cache on the
>> controller and causing premature pageout of its dirty pages?
>>
>> If you could get the readahead to work on the drive and not return
>> data to the controller, that might be dandy, but I'm sceptical.
>>
>> James
>>
>>
>>
>> -- Sent via pgsql-performance mailing list
>> (pgsql-performance@postgresql.org
>> <mailto:pgsql-performance@postgresql.org>)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-performance
>>
>>
>
>
>

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgsql-www] Mailserver/Majordomo problem

Hello,

On Fri, 12 Sep 2008 23:41:02 -0300 Marc G. Fournier wrote:

> I don't know of any problems ... what URL?

As i said: tried to sbscribe to committers list and clicked the
"subscribe" button. After several minutes i got the 500 error.

http://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org?func=lists-long-full&extra=pgsql-committers
http://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org

The error is "presented" by mail.postgresql.org: my own proxy has a
different error page.

----- cut -----
Internal Server Error

The server encountered an internal error or misconfiguration and was
unable to complete your request.

Please contact the server administrator, you@example.com and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.

More information about this error may be available in the server error
log.
----- cut -----

By the way, it's still not working.

Thanks & bye

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [GENERAL] about partitioning

On Thursday 11 September 2008 07:47:00 Joao Ferreira gmail wrote:
> Hello all,
>
> my application is coming to a point on which 'partitioning' seems to be
> the solution for many problems:
>
> - query speed up
> - data elimination speed up
>
> I'dd like to get the feeling of it by talking to people who use
> partitioning, in general..
>
> - good, bad,

good :-)

> - hard to manage, easy to manage,

I think the upfront costs for managing a partitioning setup are higher with
postgres than other systems, but there is nothing that you shouldn't be able
to automate in a cron script (at which point management becomes easy), plus
postgres gives you some interesting flexibility that is harder to find in
other setups.

> - processing over-head during INSERT/UPDATE,

you can setup inserts to have relativly little overhead, but it requires more
management/maintence work up front. Updates within a partition also have
relativly little extra overhead, especially if you put in a little
application logic to figure out how to work on a partition directly. Updates
where you are changing the partition key value are always more problematic
though.

> - stability/compatibility of pg_dump and restore operations,

no real issues here as long as your on recent enough versions to do wildcard
table matching for individual tables.

> - how many partitions would be reasonable for read _and_ write access
> optimal speed;
>

again, this depends on how exactly your working on the data. For example, we
have tables with over a thousand partitions on them; in those scenarios all
data is written into a single partition (with a new partition created daily),
and the qeury patterns are really straightforward... last month gets a lot of
queries, lasat three months not so much, last year barely any, and beyond
that is pretty much just archive info. That said, we have other systems where
that wouldnt work at all (for example, a static number of partitions, all of
which are queried activly).

For some more info, I've given at least one presentation on the topic, which
seems to be missing from the omniti site, but I've uploaded it to
slideshare...
http://www.slideshare.net/xzilla/postgresql-partitioning-pgcon-2007-presentation

HTH.

--
Robert Treat
http://www.omniti.com
Database: Scalability: Consulting:

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] Proposed patch: make SQL interval-literal syntax work per spec

Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> interval ... "sql_standard"..."iso_8601"...
>> "backward_compatible" ...depends... on ... DateStyle...
>
> ...How about decoupling interval_out's behavior
> from DateStyle altogether, and instead providing values of IntervalStyle
> that match all the previous behaviors?

Great. That seems much more sane.

Any desired names for the existing interval styles?

Currently we output intervals in these two styles:
'1 year 2 mons 3 days 04:05:06'
when the DateStyle is iso.
and
'@ 1 year 2 mons 3 days 4 hours 5 mins 6 secs'
when the DateStyle is sql or postgres, etc.

I'm not quite sure where those styles came from so
don't know what good names for them might be.

>> Should those ECPG functions be made identical ...
> ...
> The palloc and elog dependencies seem to be the hard part.

Interesting. So EncodeDateTime and EncodeInterval, guessing 400 or
so lines, seem sharable since at first glance they either already do or
easily could make their callers deal with all allocation and logging.

Agreed that it's a independent patch that I'll try separately.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] Restore filesystem backup

On Saturday 13 September 2008 09:07:23 Patrik Strömstedt wrote:
> Hi,
>
> I have a big problem.
>
> The backup (done nightly with pg_dump) at one of our customers sites is
> broken (well, it's overwritten and is of no use anymore). What is left is a
> filesystem backup that incudes the postgresql directories.
>
> I'm trying to restore one of the tables from this "filesystem backup"
> (employee_pass (salaries..)), that has been deleted on the live system.
>
> How (if possible), can I use this filesystem backup to restore the database
> into a working setup (off-site), from where I can retreive data from the
> one table (employee_pass).
>
> This is on Windows 2000 Server, the Postgres version is 8.01 (I know, it's
> old...)
>

Honestly you have a mess on your hands on a number of different levels. I'd be
tempted to just try copying the tables files directly between the two
directories if you can matchup the files on disk correctly. Otherwise you
might be forced to try and get some filesystem level tools going, but I'm not
sure how feasible that is on windows, especially on such an old version.
Good luck.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_restore parameters

On Friday 12 September 2008 14:23:52 Kevin Duffy wrote:
> Hello:
>
> I am move to a new production server and am testing my backup and
> restore procedures.
>
> Given a backup created with the follow command
>
> C:\>C:\progFiles\PostgreSQL\8.2\bin\pg_dump -Fc -b -C -o -f
> E:\backupPostgres\benchxx_c20080912.backup -U postgres benchxx_c
>
> What is the best way to do a restore of the above backup? I tinkered
> with a couple of scenarios.
>
> The one the gave a clean restore was
>
> a) drop the database
>
> b) restore using the following: pg_restore -C -d template1 -U
> postgres "E:\data\postgres\ benchxx_c20080912.backup"
>
> Is this the correct way to do a restore?
>

Well, you need to add the -Fc flags on the restore at a minimum, but otherwise
TIAS.

Also, the use of -o is kind of a warning sign to possible bad schema design,
you shouldn't be using oids for anything, are you sure you need that flag? If
you do you might want to think about factoring that out of your design, if
not then verify you need the -b flag too.

As a final though, if you're already going through the pain of a dump/restore,
I'd suggest looking at upgrading to 8.3 during the process.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Is there bigintarray?

On Sat, 13 Sep 2008, Dmitry Koterov wrote:

> Hello.
>
> We have a good intarray contrib module which contains a lot of features:
> additional functions, operators with GIN support etc.
>
> Are there plans for bigintarray?

contrib/intarray has GiST index, not GIN, which has basic support
for bigint[].

We have item in our TODO list
http://www.sai.msu.su/~megera/wiki/TODO
GiSTarray - intarray for all built-in data types - 1 week

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Fastest way to restore a database

On Friday 12 September 2008 15:55:46 Tom Lane wrote:
> Scott Ribe <scott_ribe@killerbytes.com> writes:
> >> The worry expressed upthread about the transaction being "too large" is
> >> unfounded, btw. Unlike some other DBs, PG doesn't have a finite-size
> >> undo log.
> >
> > Sure, it won't fail. But would there be some point at which it would
> > become slower than multiple transactions? Or is it always faster (or at
> > least as fast)?
>
> I can't think of any reason it would be slower.
>
> There are certainly issues you could run into with very long
> transactions, like vacuum not being able to remove bloat elsewhere.
>

Which reminds me (and not seeing it elsewhere), on full restores you will
probably want to disable autovacuum entirely, as it will compete for
reasources and can lead to locking issues as well. Note, this can sometimes
apply to more narrow restore scenarios, but it isnt as cut and dried. (Ie,
with multiple database in a cluster, you dont want to disable it for all
databases, though it'd be nice to disable it for the one you're restoring)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[torontopug] September meeting?

Is there an interest in a September meeting?

At last months meeting there was talk about having another pub night in
September and maybe trying for speakers again in October?

I suspect we'd have it at the Rhino again (unless someone has a strong
preference for another location).

If we do want speakers in October we need to decide the topics, presenters
and location.

--
Sent via torontopug mailing list (torontopug@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/torontopug

[GENERAL] Is there bigintarray?

Hello.

We have a good intarray contrib module which contains a lot of features: additional functions, operators with GIN support etc.

Are there plans for bigintarray?

Re: [GENERAL] TSearch2: find a QUERY that does match a single document

explain analyze
select * from test.test_tsq
where to_tsvector('400000x400000') @@ q

why do you need tsvector @@ q ? Much better to use  tsquery = tsquery

test=# explain analyze select * from test_tsq where q = '400000x400000'::tsque>
                                               QUERY PLAN
-----------------------------------------------------------------------------------------------------------
 Seq Scan on test_tsq  (cost=0.00..16667.01 rows=1 width=38) (actual time=129.208..341.111 rows=1 loops=1)
  Filter: (q = '''400000x400000'''::tsquery)
 Total runtime: 341.134 ms
(3 rows)

M-mmm... Seems your understood me incorrectly.

I have to find NOT queries which are exactly equal to another query, BUT queries which MATCH the GIVEN document. '400000x400000' was a sample only, in real cases it will be 1-2K document.

Here is a more realistic sample:

explain analyze
select * from test.test_tsq
where to_tsvector('
  Here is a real document text. It may be long, 1-2K.
  In this sample it contains a lexem "400000x400000", so there is a tsquery
  in test_tsq.q which matches this document. I need to find all such queries fast.
  Of course, in real cases the document text is unpredictable.
') @@ q

 

QUERY PLAN
Seq Scan on test_tsq  (cost=0.00..17477.01 rows=800 width=36) (actual
time=68.698..181.458 rows=1 loops=1)
 Filter: ('''400000x400000'':1'::tsvector @@ q)
Total runtime: 181.484 ms

'800' is the number of estimated rows, which is not good, since you got only 1 row.

Why 800? The table contains 800000 rows, and seqscan is used. Does it scan the whole table or not? If yes, possibly there is a bug in explain output? (No mater if I create GIST index on test_tsq.q or not, the number of rows is still 800, so it seems to me that GIST index is not used at all.)

Re: [HACKERS] 8.3.3 compiler warnings with gcc 4.3

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:
> I'm getting these on Fedora-9:
> tqual.c:115: warning: inlining failed in call to ‘SetHintBits’: call is

They're just cosmetic. We don't generally worry about fixing cosmetic
warnings in back branches.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[JDBC] Informacion del JDBC

Estimado grupo de Programadores:
 
Actualmente estoy realizando un pequeño proyecto con una base de datos de postgres, esta la estoy linkando mediante una aplicacion de java, he utilizado el driver JDBC4 Postgresql, Version 8.3-603.zip que es la misma version que utilizo en postgres, el problema ha es que no me puede guardar datos en la tabla que yo estoy especificando, y me gustaria que me dijeran donde puede bajarme la documentacion de dicho driver para ver en que estoy fallando.
 

 

Jorge Luis Morales Mendez

Sistemas Computacionales

---

Conoce el perfil completo de todos tus amigos de Windows Live Messenger justo aquí: Windows Live Spaces

[HACKERS] 8.3.3 compiler warnings with gcc 4.3

I'm getting these on Fedora-9:

tqual.c:115: warning: inlining failed in call to 'SetHintBits': call is
unlikely and code size would grow
tqual.c:377: warning: called from here

tuplesort.c: In function 'comparetup_index':
tuplesort.c:2423: warning: inlining failed in call to 'myFunctionCall2':
--param large-stack-frame-growth limit reached
tuplesort.c:2474: warning: called from here

All these appear a few more times during compilation.

I'm not sure we fixed these in 8.3 branch, and wanted to post it
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

[pgsql-www] slow email

Hiya List,

I've noted that some emails have started to come in mucho delayed via
the lists. Here are the headers of an example email that exhibits this
behavior. I received two copies, one directly a mere 9 seconds after it
was sent, and the other (via the lists) took 6 days.

The hold up seems to be at 200.46.204.86 .

Any ideas, or log-clues?

Kevin

Re: [HACKERS] Noisy CVS updates

On Fri, Sep 12, 2008 at 07:27:55PM -0500, Decibel! wrote:
> On Sep 5, 2008, at 9:06 AM, D'Arcy J.M. Cain wrote:
>> ...etc. Would it be OK if I went in and added .cvsignore files to
>> keep the noise level down? I guess I could have my daily script
>> filter them out but there may be times when there really is an
>> unexpected file and I want to follow up on it.
>
> +1. It might be possible to get screwed by not doing a distclean,
> but the build time savings seems worth it (first thing I do if I get
> a build error is make clean/distclean).

maintainer-clean is even better as far as removing build errors, and
I've never noticed any time difference between it and clean or
distclean.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] "Healing" a table after massive updates

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> Incidentally the visibility bugs are indeed entirely fixed in 8.3. In 8.2 and
>> before cluster and alter table rewrites can both cause tuples to not appear
>> for transactions which were started before the cluster or alter table such as
>> a long-running pg_dump.
>
> AFAIK that's true only for CLUSTER, not ALTER TABLE. There would be a
> bunch of logical inconsistencies in altering rows and then pretending
> you hadn't.

Uh, what's true? That the bugs are fixed or that we ever had them to begin
with?

Oh, are you saying that ALTER TABLE doesn't go through the rewrite code to
carry along old versions of the tuples because it can't alter the old
versions? That is a bit annoying. That means there's no safe way to do a table
rewrite without clustering the table?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgsql-www] event removed

Hi folks,

I've "unapproved" the event "Workshop with Bruce Momjian at São Paulo" (you
can view it at http://www.postgresql.org/about/event.715 untill the next site
refresh) since Bruce has canceled his attendence. If it is planned to go on
anyway, please let us know how we should change the wording (or just resubmit
it with new info). Thanks.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [pgsql-www] Question about event applicability...

On Friday 12 September 2008 15:54:49 Dave Page wrote:
> On Fri, Sep 12, 2008 at 8:52 PM, Chander Ganesan <Chander@otg-nc.com> wrote:
> > I'll be presenting at the Georgia 37th University System Annual Computing
> > Conference in Rock Eagle Georgia in October on two PostgreSQL-related
> > topics.
> >
> > One is related to choosing an Open Source database (PostgreSQL vs MySQL),
> > the other is about PostgreSQL with PostGIS spatial extensions.
> >
> > Would either/both of these events be things that would be appropriate on
> > the "events" section of the main web site?
>
> I don't see why not - they are both of interest to our users/potential
> users.
>

Except, this seems like one event, "the Georgia 37th University System Annual
Computing Conference", but be sure to mention both talks in the description
(and list any other advocacy activities / folks that might be going)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [GENERAL] "Healing" a table after massive updates

Gregory Stark <stark@enterprisedb.com> writes:
> Incidentally the visibility bugs are indeed entirely fixed in 8.3. In 8.2 and
> before cluster and alter table rewrites can both cause tuples to not appear
> for transactions which were started before the cluster or alter table such as
> a long-running pg_dump.

AFAIK that's true only for CLUSTER, not ALTER TABLE. There would be a
bunch of logical inconsistencies in altering rows and then pretending
you hadn't.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Possible limit on transaction size?

bbeyer@purdue.edu writes:
> About 150 million records into the import process, I get the following error:

> ERROR: lock AccessShareLock on object 51533/51769/0 is already held

What PG version? Can you put together a self-contained test case?
(It's probably independent of the data, so you could make a script that
just processes a lot of dummy data the same way you are doing.)

There was a similar report a couple of weeks ago:
http://archives.postgresql.org/pgsql-bugs/2008-08/msg00264.php
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00021.php
but that person hasn't gotten back to us on determining exactly
what happened.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] detecting recurring appointment conflicts

I'd like to store recurring appointments in my database, and be pretty
accepting in the scheduling of those appointments. For instance, I
want to accept both "every other Tuesday starting 2008-11-04" as well
as "every 3rd October 13th starting 2009." Storing those appointments
isn't that hard, but what isn't at all obvious to me (and what I'm
hoping is obvious to somebody else) is how to efficiently detect if
and when overlaps will occur.

I can see a few ways to look for schedule overlaps in a defined
window, but ideally, I'd like to know if there will be overlaps at any
time, not just in, say, the next 10 years. (Though, admittedly, the
next 10 years is probably sufficient.) Is this something somebody has
tackled before?

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] "Healing" a table after massive updates

"Scott Marlowe" <scott.marlowe@gmail.com> writes:

> On Thu, Sep 11, 2008 at 8:56 AM, Bill Moran
> <wmoran@collaborativefusion.com> wrote:
>> In response to Alvaro Herrera <alvherre@commandprompt.com>:
>>
>>> Bill Moran wrote:
>>> > In response to "Gauthier, Dave" <dave.gauthier@intel.com>:
>>> >
>>> > > I might be able to answer my own question...
>>> > >
>>> > > vacuum FULL (analyze is optional)
>>> >
>>> > CLUSTER _may_ be a better choice, but carefully read the docs regarding
>>> > it's drawbacks first. You may want to do some benchmarks to see if it's
>>> > really needed before you commit to it as a scheduled operation.
>>>
>>> What drawbacks?
>>
>> There's the whole "there will be two copies of the table on-disk" thing
>> that could be an issue if it's a large table.
>
> I've also found cluster to be pretty slow, even on 8.3. On a server
> that hits 30-40Megs a second write speed for random access during
> pgbench, it's writing out at 1 to 2 megabytes a second when it runs,
> and takes the better part of a day on our biggest table. vacuumdb -fz
> + reindexdb ran in about 6 hours which means we could fit it into our
> maintenance window. vacuum moves a lot more data per second than
> cluster.

Alternative you can do

ALTER TABLE tab ALTER col TYPE <sametype> USING col;

which will rewrite the table without using an index. This is much faster but
has the same other disadvantages.

Incidentally the visibility bugs are indeed entirely fixed in 8.3. In 8.2 and
before cluster and alter table rewrites can both cause tuples to not appear
for transactions which were started before the cluster or alter table such as
a long-running pg_dump.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general